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 <[EMAIL PROTECTED]> 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 --------------------------- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 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 / --------------------------------------------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
