On Sat, May 21, 2011 at 10:08:01AM +0200, Alexander Boström wrote:
fre 2011-05-20 klockan 14:17 +0200 skrev Petr Sabata:
> #1, aka the Gentoo way
> Gentoo installs its 9base package into /usr/plan9, basically not touching
> 9base files at all. This collides with FHS and therefore would require an
> exception in Packaging Guidelines.
About /usr, FHS has this to say:
Large software packages must not use a direct subdirectory under
the /usr hierarchy.
Now that's what I said, isn't it?
We'd need exceptions in our Guidelines (it's not like we don't have any at
the
moment).
http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
> #2, aka the Debian way
> Debian installs its 9base package into /usr/lib. Well, most of it. They
> also prefix all the manpages with 'plan9-', not the binaries, though.
> This placement (provided we use %{_libdir}) introduces issues for Plan
> 9 rc shell scripts and their shebangs.
/usr/lib/9base/bin, specifically.
And /usr/lib/9base/lib...
About /usr/lib in FHS:
Applications may use a single subdirectory under /usr/lib.
Well that sounds just like what we need.
But there's also this bit:
/usr/lib includes object files, libraries, and internal binaries
that are not intended to be executed directly by users or shell
scripts.
Which doesn't work in this case.
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMIN...
> #3, aka the Fedora way?
> Should we do this in some other way?
Fedora + FHS doesn't seem to allow for any decent way of installing
multiple user-oriented binaries with the same name. I suggest adding a
prefix "9" or "9base-" or similar to all the binaries and man pages.
You
may even make "/usr/bin/9base-foo" a symlink into
"/usr/lib/9base/bin/foo" so the user can still add the other directory
to their PATH and have the short names.
No, that would be awful.
Not just that it would require our user to rewrite all p9 scripts she hopes to
use, it would also make her life really uncomfortable if she wanted to use 9base
instead of coreutils (e.g. by adding <9base-bin> to PATH).
If the prefix solution is not acceptable then #2 is the best alternative
because it's a smaller FHS violation and doesn't clutter /usr.
In case of #2:
What about the manpages?
What about the lib vs lib64 issue?
/abo
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
# Petr Sabata