2:09 p.m.
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