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.
> 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.
> 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
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
Attachment:
signature.asc
Description: Digital signature