Re: RFC: out-of-tree module udebs
Sorry for not really responding to this earlier. I've been somewhat distracted by the GR nonsense going on... I saw the conversation with Joey on IRC yesterday, and I think my comments below are in line with that. On Sunday 24 September 2006 19:04, Max Vozeler wrote: Some possible approaches have come out of discussions during the last months - I've tried to summarize them below. All of them have their own advantages and disadvantages. I'm interested what you think and any aspects you see that I've not considered. Approach 1: Building module udebs in linux-kernel-di-* Approach 2: Building module udebs in linux-modules-di-* Approach 3: Building module udebs in module-modules-di-* I think I like 2 best. Approach 2: Building module udebs in linux-modules-di-* --- Mostly like the above, but creates a new package for each architecture that builds module udebs. It could be used for more than one out-of-tree module if the need arises. Advantages: - No delay before kernel can be updated; The package could be uploaded later. In the in between time (for arches that have already switched to the new kernel), part of the functionality of the installer will be unavailable. Seems acceptable though. Disavantages: - Update to newer kernel requires another package to be updated Acceptable. - More work for port maintainers (?) Not necessarily. As there is no need to run depmod, I would say it should be fairly straightforward to let the autobuilders take care of that. And even if not, I've already got the basic script to do the builds of linux-kernel-di-* centrally; it should be straightforward to have that support linux-modules-di-* too. Cheers, FJP pgprL7BQrph20.pgp Description: PGP signature
Re: RFC: out-of-tree module udebs
Hi all, On Thu, Sep 28, 2006 at 06:40:55PM +0200, Frans Pop wrote: In the in between time (for arches that have already switched to the new kernel), part of the functionality of the installer will be unavailable. Seems acceptable though. I think so too. I'll need to check that e.g. partman-crypto handles not being able to load loop-aes-modules anyway. I would agree that having some delay between kernel update and linux-modules-di upload would not be too bad. Not necessarily. As there is no need to run depmod, I would say it should be fairly straightforward to let the autobuilders take care of that. And even if not, I've already got the basic script to do the builds of linux-kernel-di-* centrally; it should be straightforward to have that support linux-modules-di-* too. Okay. Given the central build script, I'm not sure it's worth to look into autobuilding the package right now. I imagine building on buildds can be tricky because foo-modules-kvers often depend on linux-image-kvers. So, based on (I think) all feedback received, I created a first package of this kind in /people/xam/kernel/; It includes only loop-aes-modules for now but can be extended to also handle other modules in a simple way once the need arises. cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: out-of-tree module udebs
On Thursday 28 September 2006 21:19, Max Vozeler wrote: So, based on (I think) all feedback received, I created a first package of this kind in /people/xam/kernel/; It includes only loop-aes-modules for now but can be extended to also handle other modules in a simple way once the need arises. Hmm. Seems you've only done i386... Could you add the other arches as well? pgpT0nBLEi26V.pgp Description: PGP signature
Re: RFC: out-of-tree module udebs
Max Vozeler [EMAIL PROTECTED] writes: Approach 1: Building module udebs in linux-kernel-di-* ... About the delay: It could be reduced by including all modules in linux-modules-extra-2.6, which is automatically updated whenever a new kernel version/ABI gets uploaded. Why not just add support to mark a module supporting d-i udebs and teach linux-modules-extra-2.6 to build them. That would allow us to have just one point to change/improve/fix for them. I'm aware of the problem with conflicts and like but that's a problem that needs a fix. I don't think it should be used as base for a decision. Doing that would remove the needing work from d-i team and letting maintainers to help kernel team supporting it out of d-i main modules. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: out-of-tree module udebs
On Mon, Sep 25, 2006 at 03:28:52PM +0200, Frans Pop wrote: On Monday 25 September 2006 14:55, Otavio Salvador wrote: Why not just add support to mark a module supporting d-i udebs and teach linux-modules-extra-2.6 to build them. That would allow us to have just one point to change/improve/fix for them. No. That solution has severe D-I release management implications. There is a very good reason why we build kernel udebs separately and as we do that we should also build module udebs separately. There is not really any good reason to build kernel .udebs separatedly, just custom and immobilism. Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: out-of-tree module udebs
On Monday 25 September 2006 14:55, Otavio Salvador wrote: Why not just add support to mark a module supporting d-i udebs and teach linux-modules-extra-2.6 to build them. That would allow us to have just one point to change/improve/fix for them. No. That solution has severe D-I release management implications. There is a very good reason why we build kernel udebs separately and as we do that we should also build module udebs separately. pgpnCH1JKv78Y.pgp Description: PGP signature
Re: RFC: out-of-tree module udebs
Frans Pop [EMAIL PROTECTED] writes: On Monday 25 September 2006 14:55, Otavio Salvador wrote: Why not just add support to mark a module supporting d-i udebs and teach linux-modules-extra-2.6 to build them. That would allow us to have just one point to change/improve/fix for them. No. That solution has severe D-I release management implications. There is a very good reason why we build kernel udebs separately and as we do that we should also build module udebs separately. It'll be separately. linux-modules-extra uses package-source package to build the binary and when doing it, we would build the need udeb together. I think it's better then waiting for processing of each binary to be able to upload the linux-kernel-di source package and use it to build the udeb. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: out-of-tree module udebs
On Monday 25 September 2006 18:30, Otavio Salvador wrote: It'll be separately. linux-modules-extra uses package-source package to build the binary and when doing it, we would build the need udeb together. No. You _cannot_ build udebs from the same source package as regular binaries. That is the whole problem we are facing now and why Max is writing this proposal: loop-aes-modules cannot currently migrate to testing because that would break Beta 3 (needs 2.6.16 udebs), even though the new 2.6.17 debs are needed in testing because 2.6.17 has migrated. You really create huge release management problems (or at least restrictions) by linking the two. pgpvAm3ZMSS3X.pgp Description: PGP signature
Re: RFC: out-of-tree module udebs
Frans Pop [EMAIL PROTECTED] writes: On Monday 25 September 2006 18:30, Otavio Salvador wrote: It'll be separately. linux-modules-extra uses package-source package to build the binary and when doing it, we would build the need udeb together. No. You _cannot_ build udebs from the same source package as regular binaries. That is the whole problem we are facing now and why Max is writing this proposal: loop-aes-modules cannot currently migrate to testing because that would break Beta 3 (needs 2.6.16 udebs), even though the new 2.6.17 debs are needed in testing because 2.6.17 has migrated. You really create huge release management problems (or at least restrictions) by linking the two. Keeping it on mind, would be better to have a linux-modules-extra-2.6-di source package then. What do you think? I don't think that's good to link linux-image-2.6-di and the external modules building. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
