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