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]
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
* subversion
* lilo
* sawfish
* python (all python packages)
* openoffice
* gnumeric
* perl (dpkg -L perl | grep /usr/lib | grep "pm$")
* tasksel
... and probably many many more ...
These was the ones that I found on a quick look on my own installation...
And there are also some directories that are common between applications
that break this (arch indep things in /usr/lib).
* /usr/lib/menu (!)
* /usr/lib/mime
* /usr/lib/emacsen-common
The sane interpretation of the FHS (which most people seem to follow)
is that you can use /usr/lib for (almost) anything that is internal to the
application (or group of applications) that is not executeables that
is supposed to be used directly by the user (from command line at least).
I know that the FHS text tell something else if you interpret it exactly
with a strict definition.
It is of course good to have arch independent files in /usr/share and
arch dependent files in /usr/lib, but would object to any attempt to
file RC bugs for such packages that violate FHS by putting arch independent
files in /usr/lib.
Just following the FHS is not a good thing in itself. I can hardly find
this issue very important as many other Linux distributions are certified for
LSB, and FHS is a required item there. Such distributions have the
same software (python, perl etc) available and thus they should not be LSV
nor FHS compliant.
But they are stated as such and by many people considered to be too.
I know that this is not a valid argument but still it point out the importance
of being strict about arch indep and arch dep files... :)
> > It is not very different from perl, python, emacs, java (and more) packages
> > that have a "filesystem" of it's own and managed there.
>
> Listing Perl, Python and Emacs here is totally wrong (and I don't know
> enough about Java packaging to speak about it). Perl is the best
> example: Architecture-dependend data is stored in /usr/lib/perl{/,5/},
> arch-indep data in /usr/share/perl. Perl scripts that are intended to be
> used directly go to {/usr,}/bin. There's not a "filesystem" in
> /usr/lib/perl, only a tree of modules.
There is a lot of arch independent data in /usr/lib for perl. Check the
files in there. First .pm file I found was arch independent and a part
of the perl package. So yes with the strict interpretation of FHS
perl also violate the FHS.
The difference is of course that this is just modules...
> > The only thing that can be argued is that the name maybe should be
> > without capital letters, but I do not think that is very important.
>
> NACK. GNUstep is not FHS-compliant and really should be fixed.
If it can be fixed, well then yes that would be a good thing. But
fixing it and breaking it at the same time, would NOT be a good thing.
I think putting all gnustep things in the gnustep usr/lib directory
is a very good compromize.
> [Please stop the top-posting and quote properly. Thanks.]
??? I did not top-post, and I did not really have anything to quote...
Regards,
// Ola
> Marc
> --
> BOFH #177:
> sticktion
--
--------------------- 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]
