[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: where do NEW packages go?

On Sun, May 19, 2002 at 03:35:20PM +0200, Jeroen Dekkers wrote:
> On Sun, May 19, 2002 at 02:00:01PM +0200, Wouter Verhelst wrote:
> > On Sun, 19 May 2002, Jeroen Dekkers wrote:
> > > I asked them what they thought about
> > > libexec and the FHS etc. and they said to me that they won't give up
> > > ABI compatibility for the FHS. So what do you think, should we get rid
> > > of both the Hurd and BSD ports or change Debian policy?
> > 
> > If what you say is true, then you should issue a policy amendment to get
> > rid of the FHS, or to allow libexec, or whatnot. You should *not*
> > blatantly ignore Debian's policy just because you think it's braindead.
> I tried to start a discussion about it first, because maybe Debian has
> some brilliant reason for not having /libexec and I was just too stupid
> to see it. But there is no brilliant and indeed filing a policy
> amendment would be a logical step. It's just that I gave up about
> Debian because I'm treated as a troll instead of being treated as
> somebody who tries to improve Debian.

I think you're being overly emotional about this.  The fact is that by and
large, the parts of the GCS that pertain to the FHS are in almost complete
agreement.  I can think of only two differences:

1. libexecdir (libexec)
2. sharedstatedir (com) [shared var]

I have not seen any usage of com.  I don't know if it is used at all, or
why it would be used.  The FHS does specify some specific files as well as
the directory hierarchy, but they seem to be mostly generic.

Unless anyone else has already/is going to submit a question to the FHS
list about libexec, then I am willing to do so.  I'll make a list of pros
and cons, so if anyone has any /reasons/ for or against it, I would be
happy to know.


Roger Leigh
                ** Registration Number: 151826, http://counter.li.org **
                Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers

Attachment: pgp6a1VNBUupr.pgp
Description: PGP signature

Reply to: