9base in Fedora?

[Nicolas Mailhot]

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