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

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



On Mon, 6 Nov 2000, Steve Greenland wrote:

> > Please reread my original post. Two of the three cases involve actual Debian
> > ports (either present or future).

Persumably this means some BSD thing that has been speculated about..

> 1. "Non-FHS ports". This seems to me a contradiction in terms. Marcus
> has weighed in with "but HURD *is* FHS", and I don't see why other ports
> can't be as well, especially as HURD is the least unix like of the
> listed OS's. If it can't be made FHS compliant, then perhaps it's not an
> appropriate target for a Debian port. What's next, and NT "port"?

Exactly, I agree with this. Ports of Debian should be as uniform as
possible. For instance, I don't see Debian doing a BSD port that didn't
use GNU Libc and didn't use our directory (mostly FHS) layout. It just
wouldn't be Debian anymore - but some weird BSD thing that used dpkg 
and some modified Debian source pckages.

> 2. "Overlay systems" (e.g. 64bit ports) Ok, this one I see, but it would
> seem to affect primarily libraries, right? And aren't they going to have

AFAIK only libraries, and the issues with overlay's are more complex than
just changing directories around. Probably you'd need to make like libc6
(for ia64) and libc6-ia32 (for ia64) which were constructed in such a way
so as to not overlap, etc, etc. You need different compiler flags, you
need to strip any shared data out, move files around, create new packages,
blah blah blah

Or something else <shrug>

> 3. "Third-party stuff". Don't care.

Sadly, yes. It has never been our mandate to make ultra portable source
packages. They are expected to work on Debian's systems and no others.
Before this could become anything more than a frill we'd probably need
something more major than a policy change (Vote?)

> > if someone files a bug that correctly solves this issue, you either
> > accept the patch, or leave the bug open at normal severity).

I disagree, supporting this could have a substantial longer term cost,
particularly if it required extensive changes to upstream source that
did not use configure.

Jason



Reply to: