Re: [RFC] Package build time config for installation directories.
On Mon, Nov 06, 2000 at 10:58:30AM -0600, Steve Greenland wrote:
> On 06-Nov-00, 10:22 (CST), Ben Collins <bcollins@debian.org> wrote:
> > >
> > > Ben, I don't really see the point of all of us spending time to support
> > > non-Debian systems. I don't have much interest in seeing dpkg take over
> > > the universe. The point of having standards such as the FHS is to avoid
> > > this kind of kludgery.
> > >
> >
> > Please reread my original post. Two of the three cases involve actual Debian
> > ports (either present or future).
>
> Ok, I did.
>
> 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"?
Hurd is probably not the best example...so I retract it as one.
> 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
> to detect architecture and special case stuff besides directory names
> (e.g. compiler switches, etc.) anyway? So this doesn't help them all
> that much.
You say this at first glance, and I am speaking as one who has actually
been dealing with trying to resolve this issue in the instance of sparc64.
Having to ask the majority of library packages to special case each 32/64
port is rediculous. They would have to hardcode each one, and new ones
would have to request their additions, so more cruft. It would be much
better for the libraries to use this method, and then the 32/64 ports to
provide their own dirs definitions. Easy, general, and simpler.
Of course you are correct. Dpkg requires some changes to understand things
like "this is a sun4u, it can install sparc and sparc64 packages, but
library deps need to be resolved within the ABI, however binary deps (like
programs that get exec'd) can be resolved with either ABI". This is much
more complex, but it is a central issue in the package manager that
doesn't need to be resolved by the packages, so it's inclusion in this
proposal is irrelevant.
> 3. "Third-party stuff". Don't care.
Third-party != non-free OS, so I hope that isn't the basis for your
opinion. Dpkg and Debian policy is a fairly powerful tool that I would
hope extends well beyond just "us". If this benefits them, it is a plus,
not a "ooops, oh well".
> > Requiring developers to accept technically competent and reasonable
> > patches to enable this is something I think should be required (e.g.
> > if someone files a bug that correctly solves this issue, you either
> > accept the patch, or leave the bug open at normal severity).
>
> Fair enough.
I was hoping this would alleviate any fears :)
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: