Re: autobuilding src:nvidia-* [non-free]
On Mon, Aug 06, 2012 at 07:03:16PM +0200, Philipp Kern wrote:
> On Mon, Aug 06, 2012 at 06:49:11PM +0200, Andreas Beckmann wrote:
> > On 2012-08-06 17:07, Philipp Kern wrote:
> > > I gathered. That doesn't answer my point, though. It is the *last* package
> > > in the archive doing so, instead of using dkms.
> > There is nvidia-kernel-dkms, too. But for historic reasons we always
> > provided prebuilt modules for stable and I don't want to change this.
>
> Copying debian-release@ and debian-kernel@ on what they think. To provide
> context (it seems that pkg-nvidia-devel@ dropped my mails or put it into a
> queue, hence they're not in a list archive): nvidia-graphics-modules seems to
> be the last package to provide pre-built kernel modules. Do we still want this
> for wheezy given the maintenance hassle if there's an ABI bump? Or is an ABI
> bump (e.g. through a security update) completely unlikely for wheezy, given
> that we managed to keep squeeze stable?
No promises, but I think it's quite unlikely that we will have to
change ABI for the standard (non-rt) configurations after release.
> > > It does mean that it needs to be updated on every kernel ABI bump.
> > Right, but that hopefully does not happen too often for stable (but the
> > next ABI bump is already scheduled, as I heard).
> >
> > > (Also in theory the ABI compatibility
> > > guarantee of the Debian Linux packages is that they can add new symbols at any
> > > time, they just won't drop old ones. But I guess that's not as relevant for the
> > > nvidia packages.
> > I recently needed to rebuild it for 3.2.0-3 again because of mismatching
> > symbol versioning without ABI-bump (#683365), that should be doable by a
> > plain binNMU in the future.
>
> It could at least be compatible one-way by specifying strict dependencies onto
> the package it was compiled against. But if kernel upgrades randomly break it,
> that concerns me even more and somehow points to it being unsuitable as a
> mechanism for a stable distribution. Yes, we could possibly update the modules
> through a stable update at point release time (or maybe through
> stable-updates), but if there's already a solution that solves it: Why
> shouldn't we use it?
There is actually no attempt to check or maintain ABI stability for
packages with the rt featureset (or openvz or vserver, in squeeze), as
their stable updates have been comparatively less stable. This fact
hasn't been advertised nearly as widely as it should be.
I think we should do better and actually change the ABI numbers
per-featureset, as the current arrangement obviously works really
badly with OOT modules. But it will require more trips through NEW
and more linux-latest updates.
(I'm a little sceptical that many OOT modules work properly with
rt, but let's assume some of them do.)
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
Reply to: