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