Michael Meskes wrote: > On Fri, Oct 31, 2008 at 07:48:41PM +0100, Frans Pop wrote: >> I guess one solution could be to have virtualbox-ose not depend on >> virtualbox-modules, but on virtualbox-ose-modules-$ABI. > > Building vbox modules from lme makes no real sense to me because lme is > not supposed to be reupped for each new version of virtualbox. On the > other hand building them with virtualbox-ose makes no sense because vbos > is not supposed to be reupped for each new kernel. Sounds like a good plan. Only disadvantage is that for ABI-changing kernel updates in stable this will mean one more package to track for whoever handles those, but I'd guess that is acceptable. For a really neat and complete solution you'd IMO still need something like I proposed though to make the vbox ABI visible in package names, but that can probably be postponed until after Lenny. > How about adding a new package, virtualbox-ose-modules-2.6, mirroring > lme only for the virtualbox modules? This package could be handled by > the virtualbox team? I spend enough time debugging that I know lme quite > well and Panthera is a member of both teams, so technically this > shouldn't be a problem. Consequence would be that we'll need uploads of both l-m-e (to remove the vbox-modules package) and this new package. *If* we can be sure that for Lenny there will not be any vbox ABI changes (which I'd think is a certainty), we could also for lenny go for a pragmatic solution: just reupload l-m-e once now (built against new vbox source) and let that migrate to testing. This would get rid of the current skew and still ensure that when the kernel ABI changes, vbox modules will be properly updated. As l-m-e would need to be uploaded anyway, this seems like a reasonable option to me. The cleaner repackaging could then be done early in the Squeeze cycle. A final solution for Lenny could be to reupload 1.6.2-dfsg-6 (with epoch and possibly with added backported fixes). The upload of the new upstream to unstable really wasn't a very good idea, and neither was requesting it to migrate to testing... Cheers, FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.