Bug#225671: linux-kernel-headers: please consider making target directory configurable on build time
On Wed, Dec 31, 2003 at 06:46:50PM +0100, Marc Haber wrote:
> On Wed, Dec 31, 2003 at 04:59:48PM +0000, Colin Watson wrote:
> > Wouldn't it be much easier and less confusing to users to copy the
> > relevant headers into the packages that need them to build?
>
> Probably. But that's a politics decision. I only want my backports to
> work, and I prefer not spending entire working days for a single
> backport ;)
>
> > This has the
> > added advantage of being what you're supposed to do anyway, but it
> > should be easy enough to do that in a backport ...
>
> The problem is that my experience shows that a backport works best the
> less you have changed in the packages.
Let me offer another reason, then: backports also work best when the
change to the user's system is minimal. Yet what you're proposing is to
take a system whose glibc was built with 2.4 kernel headers and shove
2.6 kernel headers onto its include path. Now when you include libc
headers which in turn include kernel headers (which is the latter's
purpose in life), they'll inevitably pick up the 2.6 ones, and suddenly
you've changed the world under the libc's feet.
This might work sometimes - maybe even a lot of the time - but, well,
good luck untangling the mess when it does go wrong. Copying single
header files is much less invasive, and any problems you do see that way
will be much easier to debug.
> Additionally, huge backport patches make it harder to backport later
> versions.
Almost all of the patch would simply be adding files, and then you might
have a trivial change to the include path if you're unlucky. This
wouldn't be hard at all. Plus, you can probably get the maintainer to
include the same patch in later versions.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: