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

Re: [RFC] Package build time config for installation directories.



Am Son, 05 Nov 2000 22:24:35 schrieb Jason Gunthorpe:
> 
> On Sun, 5 Nov 2000, Ben Collins wrote:
> 
> > 1) Non-FHS ports have problems concering the directories where things
> >    get installed (they may not match linux directories). Darwin, FreeBSD,
> >    Hurd and many others fall into this category.
> 
> Could someone explain to me how a non-FHS 'Debian Port' is something we
> should even be thinking about doing? Is it really Debian anymore? It
> certianly isn't just a port..

I think Debian is not defined by the FHS, but the other way round:
We make good use of the FHS, because it solves a problem we have to
solve anyway, and it is a reasonable standard. We try to achieve
compliance, but our hearts don't bleed when we are incompatible at
any particular time or with any particluar issue where we have good
(or even not so good) reasons to be incompatible.

The FHS is not existantial for Debian, so I would say, yes, something
that doesn't comply to the FHS (note that there is currently no
FHS-port of Debian, all ports are incompliant, even i386-linux)
can still be Debian.

> I wasn't aware the hurd Debian folks were actually going to do that within
> Debian..

That's because Ben is not strictly correct, we are not breaking
FHS compliance at will. Indeed, the Hurd author and designer
Thomas Bushnell, BSG, was (is?) one of the early contributors
to the FHS to ensure that the Hurd *can* be compliant.

There are some things the Hurd does differently which only appear
to be incompliant at first seight, mainly that the Hurd
does not use /usr seperately from the root directory.
/usr is a symlink to "." on the Hurd (which means all libs in /usr/lib
can also be found in /lib and vice versa). Careful reading
of the FHS will show that it does allow for any directory to be a
symlink, and it doesn't say that those directories may not be
identical.

Then there are some very small issues where the Hurd is
incompliant (but it is a long time I looked into the standard).
We have two more root-level directories: /hurd (for translators,
which are special programs which can be invoked manually, are
installed manually, but usually invoked by the system).
And we use /libexec (which is IMHO a good idea), which is
something that could be changed if really, really necessary.
(Although I think that it is not a bad thing to have a little bit
diversity, which adds charm and personality to any system.
I mean, linux has some traditional exceptions in the Linux Annex,
and there is no reason there could be a Hurd Annex in the FHS
to formalize the exceptions for the Hurd. I prefer to work on
real code in the meantime, so there is something worth to be
formalized :)

Thanks,
Marcus



Reply to: