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

Re: kernel-{image,headers} package bloat breaks module builders

On Tue, Apr 24, 2001 at 03:34:40PM -0400, Sam Hartman wrote:
> placed by this scheme.  My assumption is that there will be different
> modversions for each kernel configuration and that as such, I will

That's correct.

> then my module-specific concerns go away.  Even if you accept that the
> bandwith usage/mirror load/distribution size increase simply from the
> kernel packages is acceptable, it is not clear that multiplying the

Which I is think is the case.

> number of packages (and thus to an extent some size multiplier) by the
> number of module packages is also acceptable.  Assuming that the
> number of module packages no in the kernel continues to increase,
> which I think likely, the problem will only get worse over time.

I doubt the increase is going to be that significant.  Since most of these
will eventually become part of the mainstream kernel or get dropped.

> I also am concerned about the amount of work this creates for module
> maintainers.  Now I have to rebuild a lot of packages both when my

I think your concerns are not well-founded.  If you have a sane build
system, then building them is as simple as a for loop.  Have look at the
way kernel-image-i386 is built if you don't understand what I'm talking

> trees to satisfy make-kpkg), configure the kernel trees, which
> involves grabbing the configs from somewhere (either kernel images or
> the source package) and build modules for each kernel image.

If your module source is properly constructed, you should be able to get
away with a build-depends on the appropriate kernel-headers.

> The binary modules packages (alsa and pcmcia) especially although I
> haven't been doing much better of late tend to have an annoying
> history of not being in sync with the kernel.  I'm concerned that this

I think part of the reason of them being out of sync is the way that they're
currently built.  This is also partly a result of not having corresponding
kernel-headers as these module packages then try to use the kernel-source
+ the config file directly which either means a lot of work for the
maintainer to track them down or even worse, you end up with module packages
that don't work with the kernels.

I'm happy to answer questions about how the kernel-headers can be used to
make this process easier.
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Reply to: