changes after n-g-d 194.36.31-4

[Russ Allbery]

Andreas Beckmann <debian at abeckmann.de> writes:

> the 71xx packages are ready for a new upload to unstable. They are not
> usable in testing/unstable, but they are now (nearly) installable in
> lenny (see below) and may work as a base for backports if anyone is
> interested. Since they depend on xserver-xorg-core from lenny, they
> can't migrate to testing accidently.

This is done.  I don't know that it makes a lot of sense to keep these
packages in the archive, but I didn't have any objections to uploading one
more version of them so that can make it into snapshot.debian.org or
whatever.  At some point, though, if NVIDIA isn't going to fix them, we
should probably think about pulling them.

But it can wait until after the release.

> I did a lot of install/upgrade tests of the packages uploaded recently
> and found a few missing Breaks in libgl1-nvidia-alternatives: partial
> upgrades from some bad old nvidia-glx*-dev package may break
> libgl1-nvidia-alternatives. This is fixed in -5. I also adjusted some
> more dependencies, so the package is (nearly) installable in lenny.

I looked over the changelog of what we currently have and while some of
that is borderline, it seems like a reasonable set of changes to me.  I'll
ask on debian-release whether another upload is okay.  We're currently
blocked on ia32-libs at the moment anyway, which requires another upload
before it can move to testing.

For all of the following, though, we're now in deep freeze and we're only
supposed to upload fixes for RC bugs.  Fixing the dependencies arguably
counts, but I think the rest here:

> I included the changes from 256.53-2 in my tests and recommend that we
> merge them into 194.36.31-4:
> * remove 2 unused packages libcuda1-dev and nvidia-libopencl1-dev
>   - they exist in testing (but not lenny) and their only user is nvidia-
>     cuda-toolkit (in NEW only)
>   - they will be removed in 256.xx anyway
>   - the upgrade(removal/disappearing) path is clean and works without
>     transitional packages (old libfoo-dev depends on libfoo and new
>     libfoo will Conflicts/Replaces libfoo-dev afterwards, there is no
>     Depends/Recommends: nvidia-cuda-toolkit being added since this is
>     currently not available)
> * module build updates
>   - looks fine, I had no problems building modules with module-
>     assistant and these changes

is too much change at this point in the freeze cycle.  It's unfortunate,
since that means we'll need to keep transition packages for libcuda1-dev
and nvidia-libopencl1-dev around for one release cycle, but I think it's
better to not merge these changes at this point.

> Looks like you will have to file package removal requests for
> libgl1-nvidia*-dev (and libcuda1-dev, nvidia-libopencl1-dev if we remove
> them in -5) since they are no longer being built from source and are now
> outdated (probably blocking testing migration).

This is taken care of semi-automatically by the ftp team once the source
package no longer builds the binary packages.

> For the new upstream versions I would recommend the Debian NVIDIA
> Maintainers Team does "official" backports to squeeze. Another reason
> why I'd like to get rid of the two superfluous -dev packges right now.
> Having current drivers available for stable is something the users most
> probably want to have.

I'm happy to upload backports to squeeze as well.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>