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

Re: Possibility for dependencies against specific kernel modules

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...


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: