nVidia drivers: series introduction, upgrade, deletion.

Nicolas Chauvet (kwizart) kwizart at gmail.com
Sat Oct 11 09:47:53 CEST 2008

Hi !

With this message I would particularly focus on one problem with the
nVidia driver "maintainability" via the rpmfusion_nonfree repository.

The new stable nVidia driver 177.80 has dropped support for Geforce
serie 5 (NV3X) cards. This means that if we update xorg-x11-drv-nvidia
to the 177 serie in our stable release, users will have their X sessions
to collapse.

Hence, we need to set up a simple policy about how to have the nVidia
driver updated when support range for cards has changed. The update will
have to append quietly if done within a fedora stable release (F-8/F-9
currently). But may(1) need a "documentation regression" (2) If users
want to switch to the lastest or want to upgrade (From F-8/F-9 to F-10)
having missed the xorg-x11-drv-nvidia to xorg-x11-drv-nvidia-173xx

So, to sum-up and try to keep this simple:
We need to introduce a new legacy serie as the 173xx version, splited
from the "main" xorg-x11-drv-nvidia.
- In F-8/F-9 (Fedora stable - despite I wonder if we will introduce 177
in F-8).
We will rename xorg-x11-drv-nvidia to xorg-x11-drv-nvidia-173xx (along
with the related nvidia-kmod to nvidia-173xx-kmod). That way, users with
 NV30 will not experience breakage).
Then we will introduce the 177 driver as xorg-x11-drv-nvidia-lastest
- In Rawhide (F-10) we will just update xorg-x11-drv-nvidia to 177 and
Obsoletes the 177 serie (xorg-x11-drv-nvidia-lastest) introduced in F-8/F-9.

IMO, I would prefer to introduce xorg-x11-drv-nvidia-lastest in Fedora
stable either or not it is a beta version. But I would like to reserve
this when the support range for nVidia hardware has changed.

Note on the nVidia beta drivers and repositories behaviors.
Previously on livna.org, we used to have a separate branch for packages
with F-? to F-?.testing from our svn, ending in the livna-testing
repository. Having such beta drivers in livna-testing doesn't prevent
the stable driver to be updated (or kmod to be rebuilt), and leads to
separated repositories.
As opposite, "fedora like" repositories behavior is to push update from
updates-testing and then, once QA, to the updates(stable).repo.
This behavior is particularly needed for the nVidia driver update.
But having a separate repository for blending edge beta version is missing.

One argument not to split "-beta" as another package is that there are
already lot of series to maintain (nvidia, 173xx, 96xx, 71xx). And the
reason why we split serie is driver range support (3), not driver status
So as such, beta can also be a legacy serie. (even if that's not
probable). And it will be easier to test a beta activating another repo
than to uninstall/reinstall a package.(4)

So any questions/wonders/advices ?
(This scheme will be introduced in rpmfusion only IMO)

Nicolas (kwizart)

(1) Depend if the parallel mode if validated.
 (still in WIP, but won't be activated that soon).
(2) I mean, users will have to RTFM.
(3) We can also have a nvidia-custom specs for having a particular
version packaged, but that will not be provided within the repository.
(4) Keep in mind that driver update often needs reboot (or done in
init3) to prevent version mismatch and other side effects.

More information about the rpmfusion-developers mailing list