Re: RFC: Thoughts on building modules
Sam Hartman [EMAIL PROTECTED] wrote:
Note that all of the solutions I discussed involved this complexity.
I was objecting to your implication that setting up module source
packages was as simple as setting up arch-specific kernel image
packages, not saying the complexity was unnecessary.
A lot of the complexities in module building currently arise out of poorly
constructed upstream build systems. Building a good modules package
should be as simple as supplying the right -I flag and running make.
Once you've got that the rest is quite trivial.
Unfortunately, there is no general way of fixing build systems so it has
to be done on a case-by-case basis. There's no way around it I'm afraid.
I'd buy that if all three potential directions I presented in my first
message weren't ways around this. Module packages really aren't that
different from normal packages; there is a lot of kernel code that is
not arch specific. I agree that kernel packages are arch specific and
If you succeed in finding a way I'd love to hear it. However, I am
doubtful whether such a way exists as in the end, you need to have one
module package per kernel-image package. And the kernel-image packages
are arch-specific, so there has to be some arch-specific elements in
your source package. There's nothing stopping you from aggregating this
all into the one source package. However, as you have pointed out
earlier, this has the unfortunate consequence of requiring a global udpate
when a single architecture changes.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: RFC: Thoughts on building modules
Sam Hartman [EMAIL PROTECTED] wrote:
I see three options. We can have the modules built out of the main
source package that also produces the architecture: all package
containing the tarball for end users to use with kernel-package.
Alternatively, we can have a separate modules source package for
building only the module; this has the advantage of separating the
module components from other components of the system, which is nice
for things like PCMCIA and Openafs that have significant userspace
components. We could also try and get module building integrated into
stock kernel source packages; this would have the advantage of
I personally prefer a variant of the second option, have a per-arch source
package which build-depends on a module-source .deb produced by the main
module source package. The reason it has to be per-arch is given later in
your message, i.e., you don't want to recompile the i386 modules if the
alpha kernel gets updated. The same per-arch package should build-depend
on the respective kernel-headers packages for the images that it wants to
build against.
BTW, this is how the kernel images are organised on alpha/i386/sparc.
If your module needs stuff outside kernel-headers, either it's doing
something wrong, or there's stuff in the kernel that needs to be moved
under include/.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: RFC: Thoughts on building modules
Herbert == Herbert Xu [EMAIL PROTECTED] writes: Herbert BTW, this is how the kernel images are organised on Herbert alpha/i386/sparc. This is misleading. The kernel-image-*-arch packages are much simpler because they do not depend both on a kernel source package and on a module deb package. Also, note that this maximizes work for the module maintainer, which is a valid thing to do, although I'd like to note that we seem to get a much better balance for other porting issues. Finally, it means that I cannot release a module for a new arch without package-installation access to that arch. It's my understanding that source-only uploads only work if there is an existing binary package that depends on the source package being installed, which is not the case for new package source uploads.
Re: RFC: Thoughts on building modules
Sam Hartman [EMAIL PROTECTED] wrote:
This is misleading. The kernel-image-*-arch packages are much simpler
because they do not depend both on a kernel source package and on a
module deb package. Also, note that this maximizes work for the
How does that make it more complex?
issues. Finally, it means that I cannot release a module for a new
arch without package-installation access to that arch. It's my
understanding that source-only uploads only work if there is an
existing binary package that depends on the source package being
installed, which is not the case for new package source uploads.
Well, kernels/modules have traditionally required this kind of access.
There's no way around it I'm afraid.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: RFC: Thoughts on building modules
Herbert == Herbert Xu [EMAIL PROTECTED] writes: Herbert Sam Hartman [EMAIL PROTECTED] wrote: This is misleading. The kernel-image-*-arch packages are much simpler because they do not depend both on a kernel source package and on a module deb package. Also, note that this maximizes work for the Herbert How does that make it more complex? It has two sets of factors driving changes. Tools designed to make this maintaince process easier will be more complex than tools designed to make maintaining kernel source packages for a single arch easy. Well, at least you have a complexity vs manual effort tradeoff. I argue that currently the tradeoff is way too far on the side of manual effort and that we need more complexity. Note that all of the solutions I discussed involved this complexity. I was objecting to your implication that setting up module source packages was as simple as setting up arch-specific kernel image packages, not saying the complexity was unnecessary. issues. Finally, it means that I cannot release a module for a new arch without package-installation access to that arch. It's my understanding that source-only uploads only work if there is an existing binary package that depends on the source package being installed, which is not the case for new package source uploads. Herbert Well, kernels/modules have traditionally required this Herbert kind of access. There's no way around it I'm afraid. -- I'd buy that if all three potential directions I presented in my first message weren't ways around this. Module packages really aren't that different from normal packages; there is a lot of kernel code that is not arch specific. I agree that kernel packages are arch specific and you aren't going to get away from that. However, my point is partially that module packages have different constraints that kernel packages.
