nVidia drivers: series introduction, upgrade, deletion.

Thorsten Leemhuis fedora at leemhuis.info
Sat Oct 11 16:09:28 CEST 2008


On 11.10.2008 09:47, Nicolas Chauvet (kwizart) wrote:
> 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.

+1

> Hence, we need to set up a simple policy about how to have the nVidia
> driver updated when support range for cards has changed.

I don't think defining a policy is worth the trouble, as that doesn't 
happen frequently. Keeping what we do now in mind for the future should 
do the trick; we then can on a case by case basis decide what to do 
(often it will look similar, but that IMHO doesn't warren defining and 
documenting a policy)

> The update will
> have to append quietly if done within a fedora stable release (F-8/F-9
> currently).

"append quietly"?

BTW, F-8 is EOL soon. I would simply ignore the 177 series for F8.

> But may(1) need a "documentation regression" (2)

A regression IMHO where hardware gets broken IMHO is not acceptable if 
avoidable. And it IMHO is avoidable: simply don't ship the new driver 
then. Sure, that's far from ideal, but still better (and quite normal on 
most other distros) then breaking systems.

A "documented regression" IMHO would only be acceptable for a update 
from F9 to F10

> 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.

You have lost me here, sorry. Might not matter much.

> 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.

Will nvidia continue to maintain the 173xx series? Otherwise we might 
run into big trouble sooner or later if adjustments for new kernels are 
nowhere to be found.

> - 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

By that you broke all the "how to install nvidia drivers on Fedora" docs 
(as you can't do special provides and obsoletes in kmods right now, thus 
"yum install kmod-nvidia" won't work). That IMHO is totally unacceptable 
:-/

We of course could enhance kmodtool to do what is needed; or provide 
meta-packages. But is that really worth all the trouble? Why not leave 
xorg-x11-drv-nvidia unchanged in F9 and introduce the newer drivers as 
xorg-x11-drv-nvidia-lastest? Once the parallel-installable stuff is in 
place and was tested on rawhide we maybe could introduce that on F-9, 
add a hard dep (to let xorg-x11-drv-nvidia track in 
xorg-x11-drv-nvidia-latest) and everything should "just work".

> - 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.

Sounds good.

> IMO, I would prefer to introduce xorg-x11-drv-nvidia-lastest in Fedora
> stable either or not it is a beta version. 

177.80 is the latest non-beta for a few days already:
http://www.nvidia.com/object/unix.html

> [...]
> 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.

Which was a whole lot of painful manual work for me. I never should have 
told you guys that this was possible.

> 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.

It's not that easy, because kmods complicate everything. A lot. And it 
conflicts with another plan I have: build kmods for kernels from 
Fedora's updates-testing repo and just move them over to the proper 
repos once the kernel gets published. A lot of users asked for that. And 
it will make shipping kmods "just in time way easier.

> 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.

Just package them with a different name  (e.g. xorg-x11-drv-nvidia-beta 
or something): KISS

> One argument not to split "-beta" as another package is that there are
> already lot of series to maintain (nvidia, 173xx, 96xx, 71xx).

Everything else is more complicated and more confusing for users IMHO. 
And with some macro tricks in the spec file it should be quite easy

> And the
> reason why we split serie is driver range support (3), not driver status
> (stable/beta).

/me got lost again

> So as such, beta can also be a legacy serie. (even if that's not
> probable).

"Highly unlikely" I'd say

> And it will be easier to test a beta activating another repo
> than to uninstall/reinstall a package.(4)

I don't buy that. I even think the scheme you outlined is quite 
dangerous, as people that cherry-pick a kernel from updates-testing will 
then get forced to beta drivers which they might not want; Even worse, 
they won't get updates for their drivers and run into trouble on the 
next kernel update. No, that way lie dragons; don't go there.

 > [...]

Cu
knurd


More information about the rpmfusion-developers mailing list