Le Lun 23 mai 2011 17:55, Matthew Miller a écrit :
On Mon, May 23, 2011 at 09:54:48AM +0200, Nicolas Mailhot wrote:
> 1. install libraries (and binaries? see 3.) in /usr/lib(64)
> > Large software packages must not use a direct subdirectory under
> > the /usr hierarchy.
> 2. provide prefixed :
> — binaries or
> — symlinks to binaries in /usr/lib(64)/foo (see 3.)
What about putting the binaries into /usr/bin/plan9/, instead of prefixing
each one individually? The FHS 2.3 specifies that mh binaries should go into
/usr/bin/mh, so there's precedent for subdirs there. (Not that our nmh
package follows that rule....)
There is no reason not to put them in /usr/lib(64). That's where common
binaries such as firefox, java, etc already reside. They all have magic env
variables to define their root for scripts and symlinks/wrappers/alternatives
in /usr/bin
What the FHS says is that if you have a widely used binary, it should go in
/usr/bin (because /usr/bin is in the standard path). /usr/bin/foo/ is *not* in
the standard path so putting stuff there is rather pointless, does not win
anything over /usr/lib(64)/foo/, and inconsistent with the rest of the system.
Since we also already ship the environment-modules package, an
env-module
for plan 9 could be included; users who want the plan 9 binaries could
either set their path manually or run "module load plan9".
This seems preferable to the "alternatives" system, since it's per-user
rather than systemwide.
alternative is only necessary if you want an un-prefixed binary in a common
path such as /usr/bin. Nothing else will get you that cleanly (for weird
versions of clean). If you do not require the possibility to have binaries
exist in un-prefixed form in /usr/bin, don't ever touch alternatives.
--
Nicolas Mailhot