nVidia drivers: series introduction, upgrade, deletion.

[Stewart Adam]

+1 for all of what you mentioned. We should definitely plan the "official"
channel of communication for users, maybe a News page on the Wiki?

I don't think it's possible [1] to have a 100% smooth upgrade path for 
users,
but this way is the best way to minimize it as much as possible. One thing
for the sake of consistency though, I think we should rename
xorg-x11-drv-nvidia-latest to xorg-x11-drv-nvidia-177 and make
xorg-x11-drv-nvidia-latest a metapackage which requires 177.

[1] I have no idea if this would work or not, but what if 
xorg-x11-drv-nvidia-latest
was a metapackage with the date as the current version. It would require
xorg-x11-drv-nvidia-173. Now, 177 comes out so we make 
xorg-x11-drv-nvidia-173
obsolete the xorg-x11-drv-nvidia-latest package, but only at that given 
version/date.
We bump the version (change the date) of xorg-x11-drv-nvidia-latest and 
then that
new package requires 177. I think this would work, but it depends if Yum 
would
want to install the xorg-x11-drv-nvidia-latest update before processing 
that the new
xorg-x11-drv-nvidia-173 package obsoletes the installed one.

Stewart

Nicolas Chauvet (kwizart) wrote:
> 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
> transition.
>
> 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
> (stable/beta).
> 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.
>
>