[Radiance-dev] Re: Radiance in Debian

[Gregory J. Ward]

Hi Bernd,

This e-mail must have caught you at a bad time -- I would consider it  
a favor if you keep a civil tone with others on this list.  Schorsch  
(Georg Mischler) is one of the principal contributors to Radiance,  
and the only other person besides myself who does regular work on the  
CVS tree.  Virtually all of his time is donated, so bear in mind that  
you are speaking with a fellow volunteer and collaborator.   
Regardless of rank and ability, no one deserves to be ridiculed in  
public for comments made, especially earnest and well-considered  
ones.  In general, I ask that posters treat each other with respect  
and listen to one another's opinions, even if they disagree.  Enough  
said.

I am not a Linux user, so I don't really consider this my problem,  
but if I were to install Radiance on a machine I managed (which I  
think I've done once or twice), I would prefer to have the binaries  
in their own separate directory as Schorsch suggests, similar to /usr/ 
X11R6/bin and /usr/local/pbm.  On my machine, Radiance sits in /usr/ 
local/ray, even though the default build script drops them in /usr/ 
local/bin.  I actually thought separate package directories was the  
norm, but you know more about Linux conventions and Debian packages  
than anyone else I know, so I trust in your authority.  However, I am  
interested to hear what others have to say on this point.  I don't  
think you want to receive complaints about crowding /usr/bin and  
causing name conflicts any more than I do.

As for naming all future Radiance programs rad-this or rad-that, it  
just isn't going to happen.  The number of programs being added is  
fewer than one per year, and what kind of sense does it make 10 years  
down the line to have 10 of 100 programs start with rad-* and the  
rest sans prefix?  Renaming everything in a go would cause dozens of  
compatibility issues like the genbox problem we've discussed ad  
nauseam, so I don't really see this as a viable solution.

Is it possible to offer a different installation directory at least  
as an option?

-Greg

> From: Bernd Zeimetz <bernd at bzed.de>
> Date: November 5, 2007 12:26:17 PM MST
>
>> Installing a package with more than 100 executables in everybodys
>> /usr/bin/ is one of the most unpleasant things you can do in this
>> context.
>
> It's not the first and not the last package which brings a lot of
> binaries. The only difference is that other large packages try to make
> it obvious where a binary belongs to, for example by adding an
> appropriate prefix. Which is something I wish for all coming additions
> to radiance - please choose an appropriate name, for example rad-foo
> instead of foo.
>
>> The standards offer the alternative of /usr/lib/<package>
>> exactly for this case.
>
> Right, for programs which are usually not executed by the normal user.
> Splitting them doesn't sound like an easy task on the first look,  
> but it
> should be possible. But this would also include that all tools know
> about the extra path without messing with $PATH.
>
>> Adding two extra paths in an user's
>> environment is a trivial exercise. Remember that your target
>> audience are Linux users, who do this all the time.
>
> Oh? I haven't touched $PATH for years now, and I wouldn't know any
> reason why I should do so. Binaries which are supposed to be  
> executed by
> a user go into /usr/bin (or /usr/local/bin, if they're not  
> installed by
> a package). To cite the FHS:
> /usr/lib includes object files, libraries, and internal binaries that
> are NOT intended to be executed directly by users or shell scripts.
>
> And I'm not going to violate that because somebody prefers to hide
> Radiance to make it even harder to use than necessary.
>
>> Those people who would fail, just because they don't know how
>> to edit their ~/.profile or ~/.cshrc, will not be able to do
>> anything useful with Radiance anyway.
>
> Bad enough, this sounds more like something to fix in Radiance. But  
> yes,
> I guess people who're able to write a makefile should be able to set
> something like RAYPATH somewhere in their environment.
>
>> Don't make life miserable
>> for the knowledgeable users because of them.
>
> If you're knowledgeable AND set extra PATHs anyway, it shouldn't be a
> problem to set your PATH to a directory where compatibility links are
> located (you should even be able to use sed!). Also this is exactly  
> the
> damn opinion why a LOT of open source tools are not usable for  
> beginners
> - they're only used by 'knowledgeable' people, why the hell should we
> make things simple non people with less knowledge? Why add
> documentations at all (this does NOT go against radiance - I'm  
> amazed by
> the detailed documentation, thanks Greg!)? And so on. If you prefer  
> that
> open source software stays something which is usable for knowledgeable
> people only, please go and hide in your cave, take the source and
> compile it to /yes/I/am/TEH/BRAIN/and/I/have/to/prove/it - you're free
> to do so.
>
>> Renaming genbox, with all the contreived workarounds that have
>> been proposed, would only solve *our* problem *for now*. But
>> because we'd occupy such a large portion of the namespace in
>> /usr/bin/, installing there would inevitably cause more problems
>> for other package authors in the future. The problems it would
>> cause for Radiance users right now have already been mentioned.
>
> A name clash may happen always. For most tools from radiance I  
> don't see
> a high chance that this will happen, although there're a few with very
> short names which are prone to such problems obviously. But as  
> Debian is
> the largest (or one of the largest) distributions, and we had only two
> name clashes, I don't see a big problem here. If you'd install _all_
> packages (including those in non-free, and packages you can't  
> install at
> the same time, and including unofficial repositories like
> debian-multimedia), you'd have
> 0 bzed at hal:~$ apt-file search /usr/bin | wc -l
> 39033
> files in /usr/bin. Feel free to create theories about the  
> probability of
> another name clash while looking at the time it took to get those  
> 39033
> files into /usr/bin.
>
>
>> (back into my cave again)
>
> Good idea.
>
> If you prefer to have a growing community Radiance must be attractive
> for new users, and as easy to use as possible. With the given examples
> and what is shipped in the radiance-materials package a not too dumb
> student should be able to create something based on that, which
> is/should (imho) at least be enough for an instructional curse.
>
> Something I also thought about was to create a webpage which allows
> people to upload photos of materials and the MacBeth chart, so at  
> least
> a big enough material base would exist for people (like students/....)
> who're interested in learning to use radiance, and who like to have a
> nice rendering at the end, but who don't need exact results at the  
> end.
> Unfortunately I doubt I have time for that soon.
>
> Best regards,
>
> Bernd