nVidia drivers: series introduction, upgrade, deletion.

[Thorsten Leemhuis]

On 11.10.2008 15:45, Stewart Adam wrote:
> +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?

We likely need an announce mailing list sooner or later. Page in the 
wiki would be nice as well. Or a kind of official blog maybe?

> I don't think it's possible [1] to have a 100% smooth upgrade path for 
> users,

Then don't ship 177 for F9 at all. F10 is near and those people that 
always want the latest and greatest drivers will switch over to it 
immediately anyway. I more and more think that's the best plan for 
nearly everyone, as it's easy doesn't require much work! And note, it's 
pretty normal on other distros and sometimes even in Fedora (look at the 
hplip drivers) to not update to the latest version in a stable release. 
The 177 drivers from nvidia are worse, F10 is near, so just wait a bit 
and everything gets sorted out easily.

> but this way is the best way to minimize it as much as possible.

I think regressions should be avoided at all cost on a stable release. 
Just like it is in kernel-development.

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

I've thought about that as well. I'm not 100% sure if that#s a good 
idea, but I suppose it is and say it's worth trying.

 > [...]

CU
knurd

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