Re: Modules packaging policy - call for discussion
On Fri, Mar 24, 2006 at 03:29:00PM +0100, Max Vozeler wrote:
> Let me try again: In order to build module packages for Debian
> kernel packages and the repackaged -di kernel packages, I need to
> know at build-time which flavours my package should try to build
> for so that I can generate debian/control accordingly. This
> information is available in the configs included in the arch/
> directory of linux-headers packages. -di kernel packages, however,
> use only a subset of these flavours. My question is: How can I
> determine the subset of flavours that are used in -di packages
> and that it makes sense to build module udebs for?
Well, ...
Currently i see only three ways to handle .udebs out of out of tree modules :
1) have the kernel and modules .udebs be built from the main linux-2.6
infrastructure, and thus export the .udebs flavours in the same way the .deb
flavours are exported. This is not the choice of the d-i team, and altough i
disagree with them on that, their opinion counts more on this. Furthermore,
i believe that the dpkg and co problems which led to the splitting of the
.udeb packages are not yet solved, and it is thus too late in the etch
release process to go this way.
2) do not build module .udebs from out-of-tree packages, and let it be the
responsability of the d-i team to extract choice modules from those
out-of-tree modules .debs to be repackaged as .debs. I don't know if the d-i
team is ready to go that way, or thought of it.
3) have some kind of .udeb meta package export the list of .udeb flavours.
This is difficult in the current setup, since the flavour lists are
distributed on all the per arch packages though, and i don't know if the d-i
team is ready to change that, or if it is even technically possible, without
going on the road to 1). Maybe a sub-1), with a single .udeb counterpart to
linux-2.6 (linux-2.6-udeb) controlled by the d-i team would be an alternative,
i don't know, if the dpkg and co problems can be solved though.
Anyway, these are the alternatives as i see them, i could have missed some
issues or possible solution, but i hope that this list will help everyone
involved see the situation clearly, even those not aware of the older
situation which gave the birth of kernel-wedge, or the controversy surrunding
the build .udebs from the common linux-2.6 package, and take a good decision
on this issue.
Friendly,
Sven Luther
Reply to: