Re: netpbm vs. pbmplus
'James A. Robinson wrote:'
>
>Chris> explicitly mentioned in FSSTND. I like it because, I like to ls in
>Chris> /usr/bin/{mh,netbm} to try to find which program I need. Perhaps the
>
>I normally use apropos and tab-completion for those purposes. If I
>apropos tif, gif, or xpm on a Debian box, I get a list of the netpbm
>programs.
>
>Without pbmplus clashing with netpbm, I support merging it in
>/usr/bin. 500+ binaries already in my /usr/bin, I wouldn't have the
>option of doing an ls of it anyway (even if I wanted to).
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.
The programs in /usr/bin are (for the most part) unrelated to each
other. So it's OK that they are thrown in together. Here is my
growing list of reasons to have /usr/bin/BIG-pkg for each BIG package
like mh, netpbm, pbmplus, scilab, Minerva, postgres, khoros, kerberos,
etc:
1. FSSTND suggests /usr/bin/mh for mh. By extrapolation other BIG
packages should get the same treatment.
2. Modularity is always a good idea in computer science! I don't see
why the /usr/bin directory should be an exception.
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
do this type of accounting too and you'd have to write scripts to get
long listings (a pain). But why not let the traditional Unix tools
continue to work as well?
4. Scripting will be easier if all the programs in the big package
are stashed in ther own place.
5. If everything under the sun goes in /usr/bin, eventually there
will be namespace conflicts. Let's avoid the problem before it
starts!
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). For example, if you have different types of uses,
in /etc/profile you could write a script that would include/exclude
/usr/bin/netpbm from the PATH based on the groups (or other system
specific criteria) which the user belongs to.
7. /usr/lib and /usr/include have lots of subdirs for similar
reasons. Sure it would be more convenient if Makefiles didn't have to
have -I/usr/include/some-include-dir -L/usr/lib/some-library, but we
don't do it that way. I'm not sure why, but I like it anyway :)
8. In sum, MODULARITY is important. I could come up with several
other situations where the flexibility offered by modularity in
/usr/bin would be useful. All of which, IMHO, outweigh the added
complexity of adding dirs to PATH.
--
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: