Re: netpbm vs. pbmplus
Hi,
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?
Some of your points about big packages/specialized big packages are
good. My only problem is where to draw the line...
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...
[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?
> 1. FSSTND suggests /usr/bin/mh for mh. By extrapolation other BIG
> packages should get the same treatment.
I asked them about this, and don't remember getting a response... :(
Ian J. has said the reason for ../bin/mh was name-space conflict.
Does anybody have any documented reference to why MH has a private
dir? The FHS doesn't seem to say why...
> 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?
> 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!
> 5. If everything under the sun goes in /usr/bin, eventually there
> will be namespace conflicts. Let's avoid the problem before it
> starts!
Ok, I can sort of see this point... But I find it doubtful. Packages
like kerberos, or S/Key enabled applications should have their own
directory, but that is obvious. It seems like we should take things
on a case by case basis. For instance, if somebody wanted pbmplus
again (namespace conflicts), it would be put in /usr/bin/pbmplus
because it has been superseded by netpbm.
> 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?
Reply to: