prebuilt modules for openvz, xen

Andreas Beckmann debian at abeckmann.de
Mon Sep 27 08:09:50 UTC 2010


On 2010-09-26 23:14, Russ Allbery wrote:
> Andreas Beckmann <debian at abeckmann.de> writes:
> 
>> I just saw the following commit log in the Debian kernel repository for
>> 2.6.32:
> 
>>     <http://svn.debian.org/wsvn/kernel/dists/?rev=16351&sc=1>
> 
>>     Refresh ABI reference files
> 
>>     Remove files for OpenVZ and Xen featuresets, where we are not
>>     trying to keep the module ABI stable.
> 
>> Does this mean, we should better not ship prebuilt modules for these
>> flavors?
> 
> Hm, I don't know.  I'm not at all sure what that means and don't know
> enough about kernel packaging to understand the implications of that
> change.

You probably know better who the right people are to forward this question.

Another issue: looks like nvidia-graphics-modules 195.36.31 will get
into testing before the corresponding drivers are. This is not a problem
now, but could this be problematic in the future? Possible scenario:
* 299.xx (driver and modules) is in testing
* 300.xx (d+m) is in unstable
* 300.xx prebuilt modules move to testing, removing 299.xx modules
  - users having 299.xx modules installed are not affected, they will
    not be removed because nvidia-glx depends on them (but metapackage
    will try to update)
  - new installation (testing) of 299.xx driver + prebuilt modules no
    longer possible

A possible solution is to add a dummy package to nvidia-graphics-modules
which depends on nvidia-kernel-source (>=
the-version-used-for-building-the-modules). This would allow to have
outdated modules in testing, but not outdated drivers. A (== $version)
would be too strict as we don't have to rebuild the modules for each
revision and an additional (<< $version+1) dependency would require to
have prebuilt modules available before a new upstream can enter testing.
Since such a change needs to go through NEW, this should target 256.xx.

Andreas



More information about the pkg-nvidia-devel mailing list