Re: netpbm vs. pbmplus
'James A. Robinson wrote:'
>
>Well, we obviously disagree here. What is a good solution? Perhaps
>we could do what somebody else suggested awhile ago: have a script
>that can make a bunch of symlinks from ../bin/pbmplus back to ../bin,
>or simply moves them, if somebody wants them in bin?
Symlinks in this situation would be ugly. I guess I see changing the
PATH as the lesser evil. The greater evil: the misery that the
hypothetical sysadmin will have to go through some months down the line
to deal with some unanticpated by us need to treat all of the netpbm
binaries at once in some shell script.
>Some of your points about big packages/specialized big packages are
>good. My only problem is where to draw the line...
20 or 30 related binaries in one package with the exception of any
package that is a basic system utility (like miscutils or somesuch).
It's arbitrary, but the best I can do.
>It would be nice to get an FHS ruling on pbmplus and netpbm, and any
>other package that has say, over 10 specialized binaries with it...
Do the right thing. Don't worry about what others think. [Is FHS an
abbrev for FSSNTD? What does the H stand for?]
>[point vs. point follows, please skip if disinterested]
>
>> There is the issue of modularity. If I ever choose to do
>> something with the netpbm/pbmplus programs, my scripting is GREATLY
>> complicated if it's not separated into its own directory.
>> [...]
>> 4. Scripting will be easier if all the programs in the big package
>> are stashed in ther own place.
>
>Could you elaborate on this point?
Imagine I get called in to install netpbm on some Slackware system.
The easiest way would be to ftp to my main Debian box and ftp the
files like this:
- cd /usr/bin
- get netpbm.tar
- cd /usr/man/man1
- mget *netpbm
This would be painful to do any other way. Note: modularity is
achieved in the man pages by appending the package name to the man
page (tcl/tk and several other packages already do this - it is good
(TM)).
>> 2. Modularity is always a good idea in computer science! I don't see
>> why the /usr/bin directory should be an exception.
>
>Modularity in what sense? I mean, sure functions and stuff are great
>in programming, but what does this have to do with file structures?
Directories are the way unix systems organize files. Modularity =
organization. Organization is good. File organization is modularity.
File organization is good. QED.
>> 3. It's easier to get accounting information for the package if it's
>> in a subdirectory (ls may still be hard, but it's doable). dpkg can
>
>But you still have /usr/lib/* and /usr/man{1,3,5}/* to deal with. If
>you take this too far, you might as well just have /opt/mh,
>/opt/netpbm, /opt/groff, /opt/gcc, and no /usr at all!
I make a distinction between basic system utilities that every Linux
system should have (groff, gcc, miscutils, etc) and specialized add-ons
which I want in my distribution, but I don't want to get confused with
the basic system utilities (so that's yet another level of
modularity/heirarchy that I think we should keep in mind).
>> 6. Since mh, netpbm, etc are special-purpose utilities, there is no
>> need to put them in /usr/bin (they aren't required by anything - they
>> are just add-ons).
>> [...]
>
>But what about TeX/LaTeX and groff, and other packages? Where do we
>draw the line for "big?" How much more of a headache is it for admins
>who want to mess with global configurations as little as possible?
groff is a basic utility. I'm not at a Debian system right now. How
many binaries are included with TeX? My ballpark idea was a 20-30
file cutoff, but I see that there are likely to be many special cases
and exceptions. I don't think netpbm is one of them!
Here is my PATH on our office linux box:
cjf@linux:/usr/local/netpbm$ echo $PATH | wc -c
171
cjf@linux:/usr/local/netpbm$ echo $PATH
~/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11/bin:/usr/andrew/bin:/usr/local/Geomview/bin:/usr/local/netpbm:/usr/local/scilab-2.1/bin:/usr/local/khoros/bin:.
See every BIG package has it's own directory! Since Unix shells hash
the files in PATH, there is no performance loss with a long PATH. I
don't think Debian needs to add these "extra" directories to the PATH
automatically. I think each site admin should be asked in the
postinst (or something).
I discussed this with a colleague who has 35 years in the computer
industry. He suggested I use the argument that it's easy for people to
change their PATH. It's VERY, VERY hard to operate on an enormous
directory. So even if only a few people need the convenience provided
by a separate directory occasionally, it would be worth separating
netpbm (and others) into separate directories. And it adds the
ability for the administrator to customize things.
So please don't lock us in with a mess in /usr/bin.
Do enjoy!
--
Christopher J. Fearnley | UNIX SIG Leader at PACS
cjf@netaxs.com (finger me!) | (Philadelphia Area Computer Society)
http://www.netaxs.com/~cjf | Design Science Revolutionary
ftp://ftp.netaxs.com/people/cjf | Explorer in Universe
"Dare to be Naive" -- Bucky Fuller | Linux Advocate
Reply to: