Radiance in Debian

radiance-dev
1

Hi Bernd,

I'm moving this discussion to radiance-dev, since that's where it really belongs. (Feel free to subscribe if you aren't.)

Having compatibility links as an option during installation is fine with me if it defaults to "yes" or provides a clear explanation of the pitfalls of not installing the links. I guess we only need a link for genbox at this point, though I would like to keep "rview" in there as well for consistency with extant documentation.

None of the tools look in the $RAYPATH directories for executables, and I don't store any there.

-Greg

···

From: Bernd Zeimetz <[email protected]>
Date: October 22, 2007 1:25:15 PM PDT

Hi Greg,

On closer inspection, my thought to check for "genbox" on inline
commands and print a deprecated warning isn't all that workable, since
there are so many places in Radiance where inline commands are
interpreted. It would require a lot of ugly and temporary code
changes. A better solution is to insert a "genbox" shell script that
prints out the deprecated message before calling "genrbox." However,
this still leaves an executable in the Radiance binary directory with
the "genbox" name conflict, at least temporarily. Unceremoniously
getting rid of genbox altogether would break 3/4 of the scene files out
there. This is not just a command entered by users -- it's in all our
scene descriptions, and changing it means changing thousands of user
files. Even if it's only a simple substitution, that's a lot to ask for
everyone to go in and change their data to accommodate a molecular
modeling system that in all likelihood hasn't yet caused a conflict for
any of us.

Yeah, but the same problem have the molecular guys with their scripts...
Also instead of changing scripts I'd add a link, nothing really
complicated imho.

I'm out of ideas. Anyone else with a brainstorm on this?

Question: Do the tools search in $RAYPATH for executables, too?

One idea: While installing the package I could ask the user if he'd like
to have compatibility links created and add those links. I'd have to
check if something like that would be allowed by the policy, though.
At least I can warn them.

Cheers,

Bernd

2

Hi Greg,

sorry for the late reply, just didn't find the time before.

Having compatibility links as an option during installation is fine with
me if it defaults to "yes" or provides a clear explanation of the
pitfalls of not installing the links. I guess we only need a link for
genbox at this point, though I would like to keep "rview" in there as
well for consistency with extant documentation.

They can't default to yes as they'd be added in automatic testing
environments (where all debconf questions are answered with the default
value) and installing the conflicting package could fail then.

I'm all open to other suggestions, we should find the final solution
within the next months, though.

Cheers,

Bernd

···

--
Bernd Zeimetz
<[email protected]> <http://bzed.de/&gt;

3

Well, I'm in a quandary on this, because I don't know how valuable having a Debian package is to the Radiance community relative to breaking most of the existing scene descriptions, if that's what it means.

-Greg

···

From: Bernd Zeimetz <[email protected]>
Date: October 26, 2007 9:39:53 AM PDT

Hi Greg,

sorry for the late reply, just didn't find the time before.

Having compatibility links as an option during installation is fine with
me if it defaults to "yes" or provides a clear explanation of the
pitfalls of not installing the links. I guess we only need a link for
genbox at this point, though I would like to keep "rview" in there as
well for consistency with extant documentation.

They can't default to yes as they'd be added in automatic testing
environments (where all debconf questions are answered with the default
value) and installing the conflicting package could fail then.

I'm all open to other suggestions, we should find the final solution
within the next months, though.

Cheers,

Bernd

--
Bernd Zeimetz
<[email protected]> <http://bzed.de/&gt;

4

Bernd, just a thought:

Can't we create a conflict between the two packages and keep the
existing 'genbox' command? After all, both seem to be very specialised
programs and I wouldn't expect them to be installed on the same system
(except university labs where the admins should know how to solve
this problem).

Thomas

···

On 26 Oct 2007, at 17:45, Gregory J. Ward wrote:

Well, I'm in a quandary on this, because I don't know how valuable
having a Debian package is to the Radiance community relative to
breaking most of the existing scene descriptions, if that's what
it means.

-Greg

5

Mmmmm...I'll put forward my suggestion again as probably the best way to both satisfy Debian's namespace requirements and keep existing scene descriptions--the ".rad" language, really--working. I'd go for putting the binaries in /usr/lib/radiance as a simple way to get them out of the main /usr/bin namespace; it is not terribly hard to add that to your path and I've been doing something similar for a very long time.

Randolph

···

On Oct 26, 2007, at 9:45 AM, Gregory J. Ward wrote:

Well, I'm in a quandary on this, because I don't know how valuable having a Debian package is to the Radiance community relative to breaking most of the existing scene descriptions, if that's what it means.

-Greg

From: Bernd Zeimetz <[email protected]>
Date: October 26, 2007 9:39:53 AM PDT

Hi Greg,

sorry for the late reply, just didn't find the time before.

Having compatibility links as an option during installation is fine with
me if it defaults to "yes" or provides a clear explanation of the
pitfalls of not installing the links. I guess we only need a link for
genbox at this point, though I would like to keep "rview" in there as
well for consistency with extant documentation.

They can't default to yes as they'd be added in automatic testing
environments (where all debconf questions are answered with the default
value) and installing the conflicting package could fail then.

I'm all open to other suggestions, we should find the final solution
within the next months, though.

Cheers,

Bernd

--
Bernd Zeimetz
<[email protected]> <http://bzed.de/&gt;

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

6

Hi All,

I will add my vote for Randolph's suggestion, this is what we have been doing as well (for a long time too), put both Radiance related binaries into a separate path location as well as Radiance related libs. This seems much cleaner as far as managing what amounts to a specialized toolset anyway.

Regards,

-Jack de Valpine

Randolph Fritz wrote:

···

Mmmmm...I'll put forward my suggestion again as probably the best way to both satisfy Debian's namespace requirements and keep existing scene descriptions--the ".rad" language, really--working. I'd go for putting the binaries in /usr/lib/radiance as a simple way to get them out of the main /usr/bin namespace; it is not terribly hard to add that to your path and I've been doing something similar for a very long time.

Randolph

On Oct 26, 2007, at 9:45 AM, Gregory J. Ward wrote:

Well, I'm in a quandary on this, because I don't know how valuable having a Debian package is to the Radiance community relative to breaking most of the existing scene descriptions, if that's what it means.

-Greg

From: Bernd Zeimetz <[email protected]>
Date: October 26, 2007 9:39:53 AM PDT

Hi Greg,

sorry for the late reply, just didn't find the time before.

Having compatibility links as an option during installation is fine with
me if it defaults to "yes" or provides a clear explanation of the
pitfalls of not installing the links. I guess we only need a link for
genbox at this point, though I would like to keep "rview" in there as
well for consistency with extant documentation.

They can't default to yes as they'd be added in automatic testing
environments (where all debconf questions are answered with the default
value) and installing the conflicting package could fail then.

I'm all open to other suggestions, we should find the final solution
within the next months, though.

Cheers,

Bernd

--
Bernd Zeimetz
<[email protected]> <http://bzed.de/&gt;

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction

7

If creating a special Radiance binpath is not acceptable, another solution is to create the following scene fixing utility for distribution with Debian Linux Radiance distributions. A little messy, but it would work.
-Chas

···

==============

#!/bin/sh $1
# fixgenbox: fixes Radiance scene files for Debian Linux installations with "genrbox" command
cp $1 $1.old
/usr/bin/sed /\!genbox/s//\!genrbox/ $1.old >! $1

8

Charles Ehrlich wrote:

If creating a special Radiance binpath is not acceptable, another solution is to create the following scene fixing utility for distribution with Debian Linux Radiance distributions. A little messy, but it would work.

Sorry for my late reply, but I'm missing a bit free time for packaging
work these days.

Creating an extra bin path is not a problem, but this makes things
unnecessarily confusing for new Radiance users. If you'd like to see the
Radiance community grow (which is one of the reasons why I've started to
work on a package for Debian - Radiance is too good to hide it somewhere
in a small, closed community), things should be as easy as possible.
This includes binaries in $PATH and their manpages within the manpath.
I've rarely seen a program which comes with such a good documentation in
form of manpages, it would be a shame to hide them, just because we move
all tools into a non-public path.

For those people who add an extra path to their PATH anyway:
What about creating a directory which contains the compatibility
symlinks, so you can add this directory to your PATH?
Like a directory /usr/lib/radiance/compat, with the following synlinks
as contens:

bin/genbox -> /usr/bin/genrbox
bin/rview -> /usr/bin/rvu
share/man/man1/genbox.1.gz -> /usr/share/man/man1/genrbox.1.gz
share/man/man1/rview.1.gz -> /usr/share/man/man1/rvu.1.gz

This would also allow you to add /usr/lib/radiance/compat/share/man to
the manpath to have the manpages available. And new users are able to
use genrbox/rvu without any extra hassle.

Would this solve the problem?

Also I'd like to know if there're other wishes regarding the Dbeian
package, if so, I'd like to change things now before it needs to be done
in a hurry later, and before more new users get used to the current
structure.

Best regards,

Bernd

···

--
Bernd Zeimetz
<[email protected]> <http://bzed.de/&gt;

9

Can't we create a conflict between the two packages and keep the
existing 'genbox' command? After all, both seem to be very specialised
programs and I wouldn't expect them to be installed on the same system
(except university labs where the admins should know how to solve
this problem).

No, although this would be the most easiest way to solve this, it is not
allowed and would be a policy violation:
http://www.debian.org/doc/debian-policy/ch-files.html#s10.1

···

--
Bernd Zeimetz
<[email protected]> <http://bzed.de/&gt;

10

This seems an acceptable solution to me -- having a second Radiance bin directory that people can include in their PATH to get backwards-compatibility. I have no problem with that. Does anyone else object before I implement the necessary changes?

-Greg

···

From: Bernd Zeimetz <[email protected]>
Date: November 3, 2007 1:16:31 PM PDT

Charles Ehrlich wrote:

If creating a special Radiance binpath is not acceptable, another solution is to create the following scene fixing utility for distribution with Debian Linux Radiance distributions. A little messy, but it would work.

Sorry for my late reply, but I'm missing a bit free time for packaging
work these days.

Creating an extra bin path is not a problem, but this makes things
unnecessarily confusing for new Radiance users. If you'd like to see the
Radiance community grow (which is one of the reasons why I've started to
work on a package for Debian - Radiance is too good to hide it somewhere
in a small, closed community), things should be as easy as possible.
This includes binaries in $PATH and their manpages within the manpath.
I've rarely seen a program which comes with such a good documentation in
form of manpages, it would be a shame to hide them, just because we move
all tools into a non-public path.

For those people who add an extra path to their PATH anyway:
What about creating a directory which contains the compatibility
symlinks, so you can add this directory to your PATH?
Like a directory /usr/lib/radiance/compat, with the following synlinks
as contens:

bin/genbox -> /usr/bin/genrbox
bin/rview -> /usr/bin/rvu
share/man/man1/genbox.1.gz -> /usr/share/man/man1/genrbox.1.gz
share/man/man1/rview.1.gz -> /usr/share/man/man1/rvu.1.gz

This would also allow you to add /usr/lib/radiance/compat/share/man to
the manpath to have the manpages available. And new users are able to
use genrbox/rvu without any extra hassle.

Would this solve the problem?

Also I'd like to know if there're other wishes regarding the Dbeian
package, if so, I'd like to change things now before it needs to be done
in a hurry later, and before more new users get used to the current
structure.

Best regards,

Bernd

--
Bernd Zeimetz
<[email protected]> <http://bzed.de/&gt;

11

This seems an acceptable solution to me -- having a second Radiance
bin directory that people can include in their PATH to get backwards-
compatibility. I have no problem with that. Does anyone else object
before I implement the necessary changes?

IMHO this is the best solution proposed so far, and perhaps the
Debian post-install script could ask the user whether he wants to
add the "compatibility" paths ...

About other wishes, it would be nice to add 3ds2mgf from the source
package (it is in /ray/src/cv/mgflib), or external programmes like
gendaylit (http://radsite.lbl.gov/radiance/pub/generators/index.html\).

Thanks again to Bernd and Greg for making this happen :slight_smile:

Francesco

12

Have you considered using the modules package for path management. Using modules with one command you can switch your path (or most any part of your environment) form one thing to another and then back.

Doug Reeder

···

On Nov 3, 2007, at 1:16 PM, Bernd Zeimetz wrote:

Charles Ehrlich wrote:

If creating a special Radiance binpath is not acceptable, another solution is to create the following scene fixing utility for distribution with Debian Linux Radiance distributions. A little messy, but it would work.

Sorry for my late reply, but I'm missing a bit free time for packaging
work these days.

Creating an extra bin path is not a problem, but this makes things
unnecessarily confusing for new Radiance users. If you'd like to see the
Radiance community grow (which is one of the reasons why I've started to
work on a package for Debian - Radiance is too good to hide it somewhere
in a small, closed community), things should be as easy as possible.
This includes binaries in $PATH and their manpages within the manpath.
I've rarely seen a program which comes with such a good documentation in
form of manpages, it would be a shame to hide them, just because we move
all tools into a non-public path.

For those people who add an extra path to their PATH anyway:
What about creating a directory which contains the compatibility
symlinks, so you can add this directory to your PATH?
Like a directory /usr/lib/radiance/compat, with the following synlinks
as contens:

bin/genbox -> /usr/bin/genrbox
bin/rview -> /usr/bin/rvu
share/man/man1/genbox.1.gz -> /usr/share/man/man1/genrbox.1.gz
share/man/man1/rview.1.gz -> /usr/share/man/man1/rvu.1.gz

This would also allow you to add /usr/lib/radiance/compat/share/man to
the manpath to have the manpages available. And new users are able to
use genrbox/rvu without any extra hassle.

Would this solve the problem?

Also I'd like to know if there're other wishes regarding the Dbeian
package, if so, I'd like to change things now before it needs to be done
in a hurry later, and before more new users get used to the current
structure.

Best regards,

Bernd

--
Bernd Zeimetz
<[email protected]> <http://bzed.de/&gt;

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

13

What I think is the problem is that

···

On Nov 3, 2007, at 1:16 PM, Bernd Zeimetz wrote:

For those people who add an extra path to their PATH anyway:
What about creating a directory which contains the compatibility
symlinks, so you can add this directory to your PATH?

A lot of existing scene files won't work without the additional directory in the path, and I think that new users are going to get discouraged very quickly by that. Perhaps the thing to do is to have "rad" add your links directory to the PATH it uses when it invokes oconv.

Randolph

14

There are dozens of Radiance programs that load or decode scene files, so adding the necessary path to all of them is going to involve a whole lot of code changes.

-G

···

From: Randolph Fritz <[email protected]>
Date: November 3, 2007 2:42:23 PM PDT

What I think is the problem is that

On Nov 3, 2007, at 1:16 PM, Bernd Zeimetz wrote:

For those people who add an extra path to their PATH anyway:
What about creating a directory which contains the compatibility
symlinks, so you can add this directory to your PATH?

A lot of existing scene files won't work without the additional directory in the path, and I think that new users are going to get discouraged very quickly by that. Perhaps the thing to do is to have "rad" add your links directory to the PATH it uses when it invokes oconv.

Randolph

15

Creating an extra bin path is not a problem, but this makes things
unnecessarily confusing for new Radiance users. If you'd like to see the
Radiance community grow (which is one of the reasons why I've started to
work on a package for Debian - Radiance is too good to hide it somewhere
in a small, closed community), things should be as easy as possible.

Sorry, you've lost me there. I think the point of creating a separate
path is to keep the established names while we're still able to have
everything related to Radiance in one (less common) place.

This includes binaries in $PATH and their manpages within the manpath.

$PATH can be extended and $MANPATH can be extended.

I've rarely seen a program which comes with such a good documentation in
form of manpages, it would be a shame to hide them, just because we move
all tools into a non-public path.

A separate path is not 'hiding' anything. In fact this seems to be the
most Unix/Radiance-like way of solving the problem

For those people who add an extra path to their PATH anyway:
What about creating a directory which contains the compatibility
symlinks, so you can add this directory to your PATH?
Like a directory /usr/lib/radiance/compat, with the following synlinks
as contens:

bin/genbox -> /usr/bin/genrbox
bin/rview -> /usr/bin/rvu
share/man/man1/genbox.1.gz -> /usr/share/man/man1/genrbox.1.gz
share/man/man1/rview.1.gz -> /usr/share/man/man1/rvu.1.gz

This implies that we do rename 'genbox' which is not necessary if there
is a separate path. And if we end up creating a 'compat' directory it
should not contain links to the real man page but a man page that informs
the user about the name change and advises to use the new name instead.
The binary links are necessary for existing scripts but I'm not sure if
'rview' is still necessary. It's interactive after all so everyone who
uses the wrong binary is presented with an error message as a reminder.

To come to an end: I don't thing there is a big problem with existing
scenes/scripts breaking due to the renaming of 'genbox'. I don't think
there is a big sharing of scene files going on so everyone who's new to
Radiance will write their own scenes and hopefully get a set of updated
documents to assist them. The bundled examples should be easy to update,
just as the various scripts out there (like my own). The source distribution
can create a link in the standard Radiance bin/ directory and expect the
users/admins to extend the path if necessary, Debian can moves these
links to another place and only hack $PATH if compatibility is desired.

We will get a few more mails to the list but as the 'rvu' experience shows
it's nothing we couldn't handle. All in all it seems not such a big problem
whatever we do.

Regards,
Thomas

···

On 3 Nov 2007, at 20:16, Bernd Zeimetz wrote:

16

If it's added to rad, though, and the programs rad invokes inherit it, at least basic scene files will work with the most common rendering program. It's not a perfect fix (I don't think we're going to find one) but it will at least get new users over the initial hump.

Randolph

···

On Nov 3, 2007, at 2:52 PM, Gregory J. Ward wrote:

There are dozens of Radiance programs that load or decode scene files, so adding the necessary path to all of them is going to involve a whole lot of code changes.

-G

From: Randolph Fritz <[email protected]>
Date: November 3, 2007 2:42:23 PM PDT

What I think is the problem is that

On Nov 3, 2007, at 1:16 PM, Bernd Zeimetz wrote:

For those people who add an extra path to their PATH anyway:
What about creating a directory which contains the compatibility
symlinks, so you can add this directory to your PATH?

A lot of existing scene files won't work without the additional directory in the path, and I think that new users are going to get discouraged very quickly by that. Perhaps the thing to do is to have "rad" add your links directory to the PATH it uses when it invokes oconv.

Randolph

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

17

Francesco Anselmo wrote:

This seems an acceptable solution to me -- having a second Radiance
bin directory that people can include in their PATH to get backwards-
compatibility. I have no problem with that. Does anyone else object
before I implement the necessary changes?

IMHO this is the best solution proposed so far, and perhaps the
Debian post-install script could ask the user whether he wants to
add the "compatibility" paths ...

No need for that, I can just drop it into the package, symlinks don't
take much space, so that's not a problem at all.

About other wishes, it would be nice to add 3ds2mgf from the source
package (it is in /ray/src/cv/mgflib),

I'll build that with the next upload. Seems it's not included in the
Rmakefile and I forgot about it. I think Greg could add this to the
programs which are build in that directory anyway.

or external programmes like
gendaylit (http://radsite.lbl.gov/radiance/pub/generators/index.html\).

If you convince the authors to put them under a free license, this is
not a problem at all. I've only looked at gendaylit, but it's license it
not free according to the Debian Free Software Guidelines.

* Don't even think of selling this software to other people, or
* distributing it commercially, that is strict and explicit no.

Worst piece in there, didn't read the rest carefully.

Some days ago I was pointed to a lot of documentation which is shipped
with Learnix (if I remember right). It would probably be interesting to
ship that with Debian, too (if the License permits to do so). If the
Learnix people are reading here - I'd be happy if we could work
something out (if I don't get any reaction I'll find an email addy and
write directly).

An other interesting option would be to provide FAI
(http://www.informatik.uni-koeln.de/fai/\) installers to install Radiance
on clusters - if anybody has a use for this.

Also I'd like to announce the availability of Radiance in my blog -
which is on planet.debian.org - as soon as the packaging seems to be
stable enough. If anybody knows a good summary about radiance, which I'd
be allowed to share (with proper reference of course) - please point me
to it.

Best regards,

Bernd

···

--
Bernd Zeimetz
<[email protected]> <http://bzed.de/&gt;

18

Adding the Radiance compatibility path, directory, and links should be the default behavior and should ask the user if he/she would like NOT to install the compatibility path add-on...only if the system currently has a "genbox" and "rview" namespace conflict. That way the default configuration includes everything needed and only with user interaction could the installation fail to produce a working installation.

-Chas

···

----- Original Message ----
From: Bernd Zeimetz <[email protected]>
To: code development <[email protected]>
Sent: Saturday, November 3, 2007 3:57:05 PM
Subject: Re: [Radiance-dev] Re: Radiance in Debian

Francesco Anselmo wrote:

This seems an acceptable solution to me -- having a second Radiance
  
bin directory that people can include in their PATH to get

backwards-

compatibility. I have no problem with that. Does anyone else

object

before I implement the necessary changes?

IMHO this is the best solution proposed so far, and perhaps the
Debian post-install script could ask the user whether he wants to
add the "compatibility" paths ...

No need for that, I can just drop it into the package, symlinks don't
take much space, so that's not a problem at all.

About other wishes, it would be nice to add 3ds2mgf from the source
package (it is in /ray/src/cv/mgflib),

I'll build that with the next upload. Seems it's not included in the
Rmakefile and I forgot about it. I think Greg could add this to the
programs which are build in that directory anyway.

or external programmes like
gendaylit

(http://radsite.lbl.gov/radiance/pub/generators/index.html\).

If you convince the authors to put them under a free license, this is
not a problem at all. I've only looked at gendaylit, but it's license
it
not free according to the Debian Free Software Guidelines.

* Don't even think of selling this software to other people, or
* distributing it commercially, that is strict and explicit no.

Worst piece in there, didn't read the rest carefully.

Some days ago I was pointed to a lot of documentation which is shipped
with Learnix (if I remember right). It would probably be interesting to
ship that with Debian, too (if the License permits to do so). If the
Learnix people are reading here - I'd be happy if we could work
something out (if I don't get any reaction I'll find an email addy and
write directly).

An other interesting option would be to provide FAI
(http://www.informatik.uni-koeln.de/fai/\) installers to install
Radiance
on clusters - if anybody has a use for this.

Also I'd like to announce the availability of Radiance in my blog -
which is on planet.debian.org - as soon as the packaging seems to be
stable enough. If anybody knows a good summary about radiance, which
I'd
be allowed to share (with proper reference of course) - please point me
to it.

Best regards,

Bernd
--
Bernd Zeimetz
<[email protected]> <http://bzed.de/&gt;

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

19

Charles Ehrlich wrote:

Adding the Radiance compatibility path, directory, and links should be the default behavior and should ask the user if he/she would like NOT to install the compatibility path add-on...only if the system currently has a "genbox" and "rview" namespace conflict. That way the default configuration includes everything needed and only with user interaction could the installation fail to produce a working installation.

you're missing something here.
The compat links won't reside in /usr/bin. So there's no need to remove
them at all.

···

--
Bernd Zeimetz
<[email protected]> <http://bzed.de/&gt;

20

From: Bernd Zeimetz <[email protected]>
Date: November 3, 2007 3:57:05 PM PDT

Francesco Anselmo wrote:

IMHO this is the best solution proposed so far, and perhaps the
Debian post-install script could ask the user whether he wants to
add the "compatibility" paths ...

No need for that, I can just drop it into the package, symlinks don't
take much space, so that's not a problem at all.

If you need me or would like me to make changes to the makeall script, let me know. Otherwise, I'll assume you can do this on the packaging side.

About other wishes, it would be nice to add 3ds2mgf from the source
package (it is in /ray/src/cv/mgflib),

I'll build that with the next upload. Seems it's not included in the
Rmakefile and I forgot about it. I think Greg could add this to the
programs which are build in that directory anyway.

I added it and checked in the change so 3ds2mgf will be built by default in the future.

-Greg