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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
