I think that people using Binary Drivers have the knowledge to modify xorg.conf and change nvidia to nv if their systems break before xorg update.
Xorg must to be updated like another pieces of Fedora. This can't be the exception. Think in kernel and you have the answer.
IMHO this will help to improve the time of Nvidia and ATI to release drivers for Xorg 7.1
Xorg must to be updated like another pieces of Fedora. This can't be the exception. Think in kernel and you have the answer.
IMHO this will help to improve the time of Nvidia and ATI to release drivers for Xorg 7.1
----- Original Message ----
From: Leszek Matok <Lam@xxxxxx>
To: Development discussions related to Fedora Core <fedora-devel-list@xxxxxxxxxx>
Sent: Friday, July 28, 2006 7:17:21 AM
Subject: Re: Leaving?
From: Leszek Matok <Lam@xxxxxx>
To: Development discussions related to Fedora Core <fedora-devel-list@xxxxxxxxxx>
Sent: Friday, July 28, 2006 7:17:21 AM
Subject: Re: Leaving?
Dnia 28-07-2006, pią o godzinie 10:13 +0200,
Hans de Goede napisał(a):
> I keep hearing this argument, that the packages for the involved drivers
> can be made to conflict with the update. Which in essence will deprive
> all but the most technical of our users from security updates.
This is, once again, the yum bugs coming back.
Seth thinks yum shouldn't be able to downgrade packages (if you install
newer Y and encounter a regression, you can't go back to the previous
version, except for the kernel, where you can have many versions
installed).
Seth thinks yum shouldn't be able to update all packages it can when
there are a few with broken dependencies (if an update to Y is
available, but conflits with Z... packages A...W won't be updated).
(where package Y can be Xorg 7.1 we're talking about)
Seth thinks introducing 2-3 weeks long lag (this number is not
imaginary, that's a real mirror lag) of security updates, during which I
download tens of megabytes of xml data (from 20 and 19 days ago, back
and forth), is little cost (!) comparing to one temporary file on my own
machine (less than 1 KiB) and simple checking if timestamp > timestamp
(not to mention centralized server with only repo data, always up to
date).
He doesn't get my English, probably nobody else does, I don't write in
Python and maybe that's why yum still stinks ;) But let me say this
again: yum stinks. You look convinced that yum is everything the user
can get and if it works the way it works, it's everyone else responsible
to not do anything that yum can't handle gracefully.
Wrong! First of all, yum and its front ends (pup) can be changed to hold
upgrading Xorg 7.1 (and only Xorg 7.1) when there are explicit
conflicts. Secondly, the default configuration of yum in FC5 is holding
security updates for as long as two weeks (I promise you it's true,
although my record was 8 days, running "yum update" two times a day).
I said it before and I say it again: I'm convinced that NVIDIA has newer
driver almost ready (they had time and they officially stated they're
working on it few months ago) and can take us by surprise releasing it
anytime they need. I'm brave and say: NVIDIA can release appropriate
binary driver faster than yum can download security updates with its
default configuration :)
So in my opinion, it is yum to be blamed, not Xorg packager, Fedora
Project Board or anyone else making decisions, because we could do
everything to everyone (!) if only yum was a little bit friendlier.
In other words, we're all arguing about a thing that shouldn't even be
arguable.
I would miss you Hans, please don't go! :)
Lam
> I keep hearing this argument, that the packages for the involved drivers
> can be made to conflict with the update. Which in essence will deprive
> all but the most technical of our users from security updates.
This is, once again, the yum bugs coming back.
Seth thinks yum shouldn't be able to downgrade packages (if you install
newer Y and encounter a regression, you can't go back to the previous
version, except for the kernel, where you can have many versions
installed).
Seth thinks yum shouldn't be able to update all packages it can when
there are a few with broken dependencies (if an update to Y is
available, but conflits with Z... packages A...W won't be updated).
(where package Y can be Xorg 7.1 we're talking about)
Seth thinks introducing 2-3 weeks long lag (this number is not
imaginary, that's a real mirror lag) of security updates, during which I
download tens of megabytes of xml data (from 20 and 19 days ago, back
and forth), is little cost (!) comparing to one temporary file on my own
machine (less than 1 KiB) and simple checking if timestamp > timestamp
(not to mention centralized server with only repo data, always up to
date).
He doesn't get my English, probably nobody else does, I don't write in
Python and maybe that's why yum still stinks ;) But let me say this
again: yum stinks. You look convinced that yum is everything the user
can get and if it works the way it works, it's everyone else responsible
to not do anything that yum can't handle gracefully.
Wrong! First of all, yum and its front ends (pup) can be changed to hold
upgrading Xorg 7.1 (and only Xorg 7.1) when there are explicit
conflicts. Secondly, the default configuration of yum in FC5 is holding
security updates for as long as two weeks (I promise you it's true,
although my record was 8 days, running "yum update" two times a day).
I said it before and I say it again: I'm convinced that NVIDIA has newer
driver almost ready (they had time and they officially stated they're
working on it few months ago) and can take us by surprise releasing it
anytime they need. I'm brave and say: NVIDIA can release appropriate
binary driver faster than yum can download security updates with its
default configuration :)
So in my opinion, it is yum to be blamed, not Xorg packager, Fedora
Project Board or anyone else making decisions, because we could do
everything to everyone (!) if only yum was a little bit friendlier.
In other words, we're all arguing about a thing that shouldn't even be
arguable.
I would miss you Hans, please don't go! :)
Lam
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
