DEB and RPM Radiance 3R5 packages

Peter_Apian-Bennewi1 · March 31, 2003, 3:21pm

Francesco Anselmo wrote:

According to the File System Hierarchy Standard the executables are
copied to /usr/bin, the library files are put inside /usr/share/radiance,
the man files are sent to /usr/share/man and all the documentation is saved inside /usr/share/radiance/doc.

Well- thanks for your work, especially the upcoming static version and the pmap binaries. Roland will surely appreciate that. Your link was added to the list of binaries at radiance-online.
However, FHS (http://www.pathname.com/fhs/2.2/fhs-3.12.html) recommends //opt is reserved for the installation of add-on application software packages/. , which is pretty much the category for Radiance.
Solves the conflict with vim's rview too, users could add the Radiance path before the standard directories, getting Radiance's rview.

-Peter

Francesco_Anselmo · March 31, 2003, 3:55pm

Well- thanks for your work, especially the upcoming static version and
the pmap binaries. Roland will surely appreciate that. Your link was
added to the list of binaries at radiance-online.

Thank you!

However, FHS (http://www.pathname.com/fhs/2.2/fhs-3.12.html) recommends
//opt is reserved for the installation of add-on application software
packages/. , which is pretty much the category for Radiance.
Solves the conflict with vim's rview too, users could add the Radiance
path before the standard directories, getting Radiance's rview.

Right! It's the best way to solve the problem, and /opt/radiance is also the
place where I have my radiance tree. I think I'll study more the FHS documents
and the debian policy.
And tomorrow I'll update the radiance deb and rpm packages.

What about adding Radiance to the debian distribution?

···

--
ing. Francesco Anselmo
[email protected]
--
[ DREAM ]
Dipartimento di Ricerche
Energetiche e Ambientali
--
Universit� di Palermo
--
Viale delle Scienze
90128 Palermo - Italy
--
Tel + 39 091 236 302
Fax + 39 091 484 425
--

Georg_Mischler · March 31, 2003, 4:03pm

Peter Apian-Bennewitz wrote:

Francesco Anselmo wrote:

>According to the File System Hierarchy Standard the executables are
>copied to /usr/bin, the library files are put inside /usr/share/radiance,
>the man files are sent to /usr/share/man and all the documentation
>is saved inside /usr/share/radiance/doc.
>
Well- thanks for your work, especially the upcoming static version and
the pmap binaries. Roland will surely appreciate that. Your link was
added to the list of binaries at radiance-online.
However, FHS (http://www.pathname.com/fhs/2.2/fhs-3.12.html) recommends
//opt is reserved for the installation of add-on application software
packages/. , which is pretty much the category for Radiance.
Solves the conflict with vim's rview too, users could add the Radiance
path before the standard directories, getting Radiance's rview.

Well, Peter was quicker to post this short reply while I was
still typing out all the details and arguments. Anyway, here
we go:

Personally, I'm very uncomfortable with Radiance spreading
several hundred files all across /usr/*. There are simply too
many of them for this to be a good idea. But looking at the FHS
specification, there's an obvious alternative:

http://www.pathname.com/fhs/2.2/fhs-3.12.html

  3.12 /opt : Add-on application software packages
  3.12.1 Purpose
  /opt is reserved for the installation of add-on application
  software packages.

  A package to be installed in /opt must locate its static files
  in a separate /opt/<package> directory tree, where <package> is
  a name that describes the software package.

3.12.2 Requirements

"/opt" "Add-on application software packages"
<package> Static package objects

Radiance *is* an "add-on application software package", right?

So I would suggest to all the folks packaging Radiance for *nix
based systems to simply to this:

/opt/radiance3.5/bin/*

  /opt/radiance3.5/share/lib/*.cal
  /opt/radiance3.5/share/lib/*.pic
  /opt/radiance3.5/share/lib/*.dat

/opt/radiance3.5/share/demo/*/*

/opt/radiance3.5/share/doc/ps/*.ps

/opt/radiance3.5/man/man#/*.#

And eventually:

/opt/radiance3.5/lib/*.#.so
/opt/radiance3.5/lib/*.h

This has several advantages:

- We don't need to worry about name space clashes with other
software (eg. rview with vim). The choice is simply made by
placing one bin directory in front of the other in your PATH.

- You can install and use several different Radiance versions on
the same machine, by the same selection method.

- Installation is easy with or without any sophisticated package
manager (installing in /usr/* is completely unmanageable
without one).

- You can uninstall by removing a single directory (or through a
pagkage manager if you prefer).

Disadvantages:

- Currently, I think the default library paths etc. are
hardcoded into the executables, which means you need to decide
about their location at compile time.

Actually, this is not so much a disadvantage of installing in
/opt, but simply a feature of Radiance that we might want to
improve on.

It would probably be a good idea for Radiance to automatically
add the standard directories to RAYPATH, if they are found
relative to the location of the executed binary. So if eg. rpict
is run from /opt/radiance3.5/bin/rpict, then it would expect
*.cal files to be found in /opt/radiance3.5/share/lib, and prefer
to run eg. xform from its own directory. This would simplify the
use of parallel installations considerably.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Francesco_Anselmo · April 1, 2003, 11:19am

Thank you "PAB" and "schorsch" for all your comments!

I've prepared two new packages according to your advices, but
I had to post a query in the debian-devel(-italian) ml about how
to use /opt with debian packages,
because it seems that no debian packages are allowed to put
anything into /opt (maybe I'm wrong ...), since add-on packages
are not debian packages ...

There is also a few other conflicts with debian policy:

No csh scripts can be used:
begin---8<---quoting---8<---quoting---8<---quoting---8<---quoting---8<---quoting---
11.4 Scripts
[...]
csh and tcsh should be avoided as scripting languages. See Csh Programming
Considered Harmful, one of the comp.unix.* FAQs, which can be found at
http://language.perl.com/versus/csh.whynot.[41] If an upstream package comes
with csh scripts then you must make sure that they start with #!/bin/csh and
make your package depend on the c-shell virtual package.

Any scripts which create files in world-writeable directories (e.g., in /tmp)
must use a mechanism which will fail if a file with the same name already
exists.

The Debian base system provides the tempfile and mktemp utilities for use by
scripts for this purpose.
end---8<---quoting---8<---quoting---8<---quoting---8<---quoting---8<---quoting---

No environment variables should be used:
begin---8<---quoting---8<---quoting---8<---quoting---8<---quoting---8<---quoting---
10.9 Environment variables
A program must not depend on environment variables to get reasonable defaults.
(That's because these environment variables would have to be set in a
system-wide configuration file like /etc/profile, which is not supported by
all shells.)

If a program usually depends on environment variables for its configuration,
the program should be changed to fall back to a reasonable default
configuration if these environment variables are not present. If this cannot
be done easily (e.g., if the source code of a non-free program is not
available), the program must be replaced by a small `wrapper' shell script
which sets the environment variables if they are not already defined, and
calls the original program.

Here is an example of a wrapper script for this purpose:

     #!/bin/sh
     BAR=${BAR:-/var/lib/fubar}
     export BAR
     exec /usr/lib/foo/foo "$@"

Furthermore, as /etc/profile is a configuration file of the base-files
package, other packages must not put any environment variables or other
commands into that file.
end---8<---quoting---8<---quoting---8<---quoting---8<---quoting---8<---quoting---

I think I'll update the packages when I'll have received an answer ...

I told you about my plan to make also a radiancestatic package and a
radiancepmap package. Is there anybody interested in having also a
direct cache patched binary package?

···

--
ing. Francesco Anselmo
[email protected]
--
[ DREAM ]
Dipartimento di Ricerche
Energetiche e Ambientali
--
Universit� di Palermo
--
Viale delle Scienze
90128 Palermo - Italy
--
Tel + 39 091 236 302
Fax + 39 091 484 425
--

Georg_Mischler · April 1, 2003, 3:00pm

csh and tcsh should be avoided as scripting languages.

Writing this into an OS policy is condescending at best, and
arrogant at worst. If Debian wants to claim posix compliance,
then a csh variant must be present, which means users may use it
for whatever purpose they please. Some people think that [t]csh
doesn't have all the features they would like to have in a
scripting language, and there are good arguments for that. But
claiming that others may not use it for that reason is nonsense.

Fortunately, they were decent enough to use the word "should".
That makes it a recommendation that you're not bound to in any way.

[if a] package comes with csh scripts
then you must make sure that they start with #!/bin/csh and
make your package depend on the c-shell virtual package.

That's a requirement of the package manager, and probably worth
adhering to. Note that Radiance currently also includes scripts
that depend on a specific (and rather old) version of tcl/tk.
I'm not sure if making the package dependent on that would be an
equally good idea, though.

Any scripts which create files in world-writeable directories (e.g., in /tmp)
must use a mechanism which will fail if a file with the same name already
exists.

This is certainly good practise, but not critical for Radiance,
and not in your hands as a package builder anyway. Or are they
only talking about scripts that are used while *installing* the
package?

No environment variables should be used:

Another "should" that is not really up to the OS folks to decide
about. It may still be a good idea for practical reasons, though.
Note that my suggestion for Radiance to search its libraries in
certain locations relative to its binaries would bring us into
compliance with this point as a side effect.

I think I'll update the packages when I'll have received an answer ...

I'd say ignore the "should"s at will. Nothing a user can do with
your Radiance package will threaten the integrity of their
system, not even on Debian.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Francesco_Anselmo · March 31, 2003, 2:19pm

Hi to all!

I finally managed to build two debian packages for Radiance
(1 for binaries + 1 for documentation) and I also converted
them to RPM packages with alien.

The binary packages also include glrad (special=ogl) and 3ds2mgf and
the binaries have been compiled on a Debian 3.0r1 woody
Linux distribution with gcc 2.95.4.
This is not a static binary distribution
but I'm also planning to make it (in the next days).
I also think I'm going to make a pmap package, so that it can be very easy
to switch between the classic and the pmap radiance binaries.

According to the File System Hierarchy Standard the executables are
copied to /usr/bin, the library files are put inside /usr/share/radiance,
the man files are sent to /usr/share/man and all the documentation
is saved inside /usr/share/radiance/doc.

The user still has to set the RAYPATH variable, but I'm studying how to
make it automatically through a shell script (next release).

Of course, since this is my very first attempt at making a package, there is
some problems.
The bigger one is this:
  the "vim" package also has a "rview" executable:
  since the vim package is usually quite important, I decided not to have
  the radiance package conflicting with vim. So, on Debian based system, it is
  necessary to install the package by issuing the following command:
  # dpkg -i --force-all radiance_3.5.0-1_i386.deb
  in order to overwrite the /usr/bin/rview executable (very bad, isn't it?).
  On different systems it may not be a problem, for instance on my
  linux Mandrake 9.0 box rview from the vim package is put inside /bin/,
  so no overwrite occurs and apparently everything goes smoothly,
  but the system will always execute the vim rview binary, unless
  somebody erases or rename it, or changes the PATH variable.

Could anybody give me some feedback about how to solve this problem
in the best way? I think I'm going to write a message on the debian developer
mailing list too.

Could we ask to add Radiance to the main or contrib Debian distribution?

The packages are located here:

http://www.dream.unipa.it/dream/pub/dot/anselmo/radiance/packages/

I hope to get your comments/suggestions/infos/flames soon, and I also
hope to have done a useful job.

···

--
ing. Francesco Anselmo
[email protected]
--
[ DREAM ]
Dipartimento di Ricerche
Energetiche e Ambientali
--
Universit� di Palermo
--
Viale delle Scienze
90128 Palermo - Italy
--
Tel + 39 091 236 302
Fax + 39 091 484 425
--

Jeffrey_McGrew · April 1, 2003, 5:19pm

The bigger one is this:

the "vim" package also has a "rview" executable:

I ran into this same problem on Mandrake 9.0.

  On different systems it may not be a problem, for instance on my
  linux Mandrake 9.0 box rview from the vim package is put
inside /bin/,
  so no overwrite occurs and apparently everything goes smoothly,
  but the system will always execute the vim rview binary, unless
  somebody erases or rename it, or changes the PATH variable.

I simply changed the PATH for my user login; so that if I'm logged
in as anything else rview calls VIM. I hope this doesn't raise any
problems, in that my login now paths to Radiance first, and VIM
second. But so far I haven't noticed any problems.

You might want to include in the README of your RPM package
about this issue, so that newbies, like myself, can have a hope
to sort it out.

Jeffrey McGrew

Lars_Grobe · April 2, 2003, 10:24pm

Hi!

Therefore it's not always a bad idea to have those programs
that are not part of the distribution in their own directories
under /opt/Program-Name. If you install software that is not
from the distribution, you will NEVER know if there is some
conflict hidden... so I prefer not to put the app in my
distribution's paths. I can still set PATH and RAYPATH for
specific users (e.g. create a radiance user account), or
use a simple script to do these settings before you start
rendering.

Ok, to be honest... on my private box, I put all that radiance
stuff into the standard path (/usr/local/bin here) - but I know
that I never had problems with that, while a user on a shared
machine might get into trouble if he NEED vi - and can't
correct the conflicts.

CU, Lars

···

--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Bitte l�cheln! Fotogalerie online mit GMX ohne eigene Homepage!