On 2013/01/24 01:12, Phil Perry wrote:
> On 24/01/13 08:08, jdow wrote:
>> On 2013/01/23 23:55, Phil Perry wrote:
>>>
>>> Here is the announcement I made back in November that the 310.xx
>>> series nvidia
>>> drivers were dropping support for older 6xxx and 7xxx based hardware:
>>>
>>> http://lists.elrepo.org/pipermail/elrepo/2012-November/001525.html
>>
>> And how was I to know that and how was I to prevent 310 being placed
>> on a no longer supported brand new system? It's rather a bummer you know.
>>
>
> Did you read the release notes for the new driver? That's how I found out. Did
> you read my discussion thread on the issue? That's how other elrepo users found
> out and suggested the solution.

Chicken, please meet Mr. Egg. Mr. Egg, please meet Ms. Chicken. I have the
release note before an automatic update happens?

> I really don't know what you expect me to say. We have set up an email list to
> communicate with our users and we use it. We use our IRC channel too. Many
> thousands of people use the software we package. Only a very small percentage
> subscribe to the lists. There will be many people in exactly the same position
> as you. I guess when things "break" for them they will come looking for answers
> as you did, and we do our best to provide them. In this case we knew of the
> issue, we had documented the issue and we had a solution prepared and waiting
> for you. I'm really not sure what more you expect me to do for you, for free in
> my own volunteered time? I'm really sorry if you feel it's a bummer.
>
> As I said before, if you subscribe to the elrepo mailing list (or even hang out
> in #elrepo on IRC) we *will* highlight important issues that affect the software
> that we release as we did above in a discussion thread that ran for 2 months.
>
>>>
>>> No, this is the nvidia driver telling you that your hardware is no longer
>>> supported. It even tells you that you need the NVIDIA 304.xx Legacy
>>> drivers.
>>
>> That's not obvious. And I feel I have a rather perfect right to presume
>> the board should be supported. It is a brand new machine as of May last
>> year.
>>
>>> That's correct - you need to stay at the 304.xx driver as this is the
>>> *last*
>>> driver that will support your older hardware (7xxx based chipset). We
>>> released
>>> the legacy kmod-nvidia-304xx and nvidia-x11-drv-304xx packages to aid
>>> in this
>>> (see the thread linked above) and pushed them out to the main repo
>>> *before* we
>>> released the updated 310.xx series drivers.
>>>
>>> Please uninstall the kmod-nvidia driver and install the
>>> kmod-nvidia-304xx and
>>> then you can continue to receive updates from elrepo.
>>
>> I've just tried to downgrade and see what happens.
>>
>>> Nothing screwed up, nvidia simply decided it was time to move on from
>>> supporting
>>> aging hardware (~8 years old?) in the current driver release.
>>
>> Nvidia screwed up. The hardware was brand new about 8 months ago. So I feel
>> I have a perfect right to be annoyed.
>>
>
> You'd need to take that up with nvidia, or maybe even your hardware vendor why
> they are using old chipsets.
>
>> Now, how do I stop new stuff from coming in? If there is a change in what
>> is supported then it behooves somebody to provide an automated test to
>> make sure the systems keep running by not downloading updates that do not
>> fit the particular system. After all "lspci" exists, reports this line
>> "00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 7025 /
>> nForce 630a] (rev a2)", and the install could be aborted when that is
>> found and the administrator notified.
>>
>
> Yes, we had that discussion and if we knew of a way to technically implement
> that we would have seriously considered it.
>
> Please, if you can suggest a mechanism for an RPM package to know what hardware
> is present *before* it installs itself, and then prevent itself from installing
> if the correct hardware isn't present, and do all this from within a yum
> transaction, them I'm all ears. You can run such tests in %pre or %post scripts
> but by then the yum transaction is already underway and the package is set to be
> installed or is already installed. At which point the best you can do is log the
> issue to warn the user, which is *exactly* what the nvidia driver does - even
> then you didn't understand what the log entry was telling you. We didn't see any
> need to replicate that.

Hm, this might be an issue to be bumped into the RPM maintainers.

There is a trick I used with (much) older redhat versions that might apply.
I built a dummy rpm for spamassassin with a high version number so that it
would be perpetually happy with what I had and not overwrite versions I was
working with via direct downloads.

Suppose you pushed a kmod 309 version that was really a "test". Within
the test if it detects an incompatible board it sets up a download for
the 304 versions, if applicable, plus some "along side" dummy versions
numbered 500 or something. Otherwise it does nothing and allows the
310 version to load a week later.

> If you are using an installer script then it's doable, but then you also lose
> all the advancements and convenience of a package manager with automatic
> updates, not to mention kABI-tracking RPM packaged drivers that survive kernel
> updates. Nvidia uses an installer script - feel free to use that if it better
> suits your requirements.
>
> Anyway, this isn't an SL issue so lets please not clutter the SL list any
> further. I'm happy to continue the discussion on the elrepo lists or on IRC.

Agreed. I figure I'll drop it. Please drop me a brief note directly how to
prevent simply automatically downloading 310 again.

{^_^}