Re: GNUstep and FHS
On Thu, Aug 11, 2005 at 06:18:50PM -0400, Joey Hess wrote:
> Ola Lundqvist wrote:
> > Hello
> >
> > On Sat, Jul 30, 2005 at 12:00:32PM +0200, Marc 'HE' Brockschmidt wrote:
> > > Ola Lundqvist <opal@debian.org> writes:
> > > > I do not really see a problem here. All gnustep packages store
> > > > files in a (at least sort of) FHS compliant directory:
> > > > /usr/lib/GNUstep
> > >
> > > Are the files stored there only object files, libraries and internal
> > > binaries not intended to be executed directly by users? [This is quoted
> > > From the FHS]
>
> FWIW, Marc's quote is not accurate, the exact text is:
>
> /usr/lib includes object files, libraries, and internal binaries
> that are not intended to be executed directly by users or shell
> scripts.
>
> Arguably the "includes" leaves open the possibility of other files being
> in /usr/lib. Architecture specific game levels and other similar data
> files might be one example.
Thanks.
I noted however that in FHS
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA
there is a note to http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1389
"Miscellaneous architecture-independent application-specific static files and subdirectories must be placed in /usr/share."
But it is obvious that this note has not been enforced much. :)
> > If that is what we want to enforce we have to remove/fix a LOT of packages.
> > Here is just a few that break that:
> > * dpkg
>
> dpkg mostly breaks the FHS by placing large quantities of static files
> in /var/lib/dpkg. :-P
:)
> > * subversion
>
> subversion's hook scripts can be binaries as well as scripts. There's a
> README which it would be pretty silly to move to /usr/share when some of
> the the hooks it documents are in /usr/lib. Splitting the hooks and
> README up for scripts/binaries would make it harder to find useful
> hooks.
>
> > * lilo
> > * sawfish
> > * python (all python packages)
> > * openoffice
> > * gnumeric
> > * perl (dpkg -L perl | grep /usr/lib | grep "pm$")
>
> The reason these files are in /usr/lib has been previously discussed,
> IIRC.
>
> > * tasksel
> > ... and probably many many more ...
> > These was the ones that I found on a quick look on my own installation...
>
> To take the example I am most familiar with, tasksel uses
> /usr/lib/tasksel/tests/ to contain various executables, which can be
> added by third parties. Currently they are all architecture indep, but
> that could change. Making tasksel look in both /usr/share and /usr/lib
> for this is unnecessary complexity and bloat. Also, tasksel uses
> /usr/share/tasksel/ for a single specific purpose, and third party files
> can be placed there to modify its behavior, so moving anything into
> /usr/share/tasksel would break backwards compatability. So the 20k of
> arch indep data that tasksel currently puts in /usr/lib is just not
> worth the pain to remove it.
>
> We have to keep in mind the reason /usr/share was split out and not go
> overboard in splitting out architecture independent data when it doesn't
> really matter.
Agree.
> > And there are also some directories that are common between applications
> > that break this (arch indep things in /usr/lib).
> > * /usr/lib/menu (!)
>
> This is in the process of being moved to /usr/share. There's actually a
Ok.
> very good parallel with tasksel here, the difference is mostly the size
> of the directory contents.
>
> > * /usr/lib/mime
>
> Similar to /usr/lib/menu actually.
>
> > * /usr/lib/emacsen-common
>
> 52k of data is probably not enough to worry about.
>
> --
> see shy jo
Regards,
// Ola
PS. Now I did not top-post when I had something to quote, or did I?
DS.
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Annebergsslingan 37 \
| opal@lysator.liu.se 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Reply to: