[elrepo] RE driver update incompatibility issue

[Manuel Wolfshant]

On 02/07/2013 05:23 AM, Phil Perry wrote:
> On 02/02/13 14:06, Lamar Owen wrote:
>> On 01/30/2013 08:12 AM, Phil Perry wrote:
>>>
>>> I may have jumped the gun here somewhat. Managing the kernel module is
>>> probably the easy part. I forgot about the hard part, and that is
>>> managing the many linked X11 libraries that are also version-specific.
>>
>> Ok, another track here.
>>
>> Phil, how difficult do you think it would be to have all the packages be
>> installable both individually and side-by-side? That is, have multiple
>> versions of the kmod and the X bits installed, into different
>> nonconflicting directors? Then, use alternatives to manage the different
>> trains? That way, I could install the legacy train with the mainline
>> installed, switch to it with alternatives, and uninstall the mainline,
>> which wouldn't break dependencies. And, when/if I upgrade my video card
>> I can install the mainline, switch to it, and uninstall the legacy,
>> again without breaking deps or configs. I have no idea how difficult
>> that would be, either.
>>
>
> I guess that sounds doable in principle.
>
> Without knowing how alternatives works, I guess installing each 
> package in it's own space, and then have some script copy all the 
> files to their correct location based on which driver is selected, 
> create the symlinks etc and do any other housekeeping tasks is what 
> would be required. If one can do those things from within a RPM 
> package then I see no reason why a script couldn't handle it too. You 
> would have to call weak-modules to handle the kABI tracking kernel 
> module.
alternative  installs each set of files belonging to a package in a 
separate folder and uses/manages  symlinks to link
- the real file to /etc/alternatives/somelocation
- /etc/alternatives/somelocation to the place where the result should be

for instance

[wolfy at wolfy ~]$ ls /usr/lib/sendmail -l
lrwxrwxrwx. 1 root root 30 Jun  7  2011 /usr/lib/sendmail -> 
/etc/alternatives/mta-sendmail

[wolfy at wolfy ~]$ ls -l /etc/alternatives/mta-sendmail
lrwxrwxrwx. 1 root root 25 Jun  7  2011 /etc/alternatives/mta-sendmail 
-> /usr/lib/sendmail.postfix

All symlinks are manipulated via alternatives add|remove|set | other 
commands. At least that is the theory.
A simple example can be found at line 94 here: 
http://pkgs.fedoraproject.org/cgit/ssmtp.git/tree/ssmtp.spec


>
> TBH, any such solution is (a) going to require a major non-trivial 
> rewrite and (b) significantly diverges from the packaging paradigm. 
> For these reasons I'm extremely reluctant to pursue such a solution if 
> for no other reason that adding such complexity is almost certainly 
> going to add an increased risk of unreliability.
Actually it's not very complicated. It's just a looooooong command.


>
>
>> Or maybe a check in %pre that can abort installation of the driver if
>> the hardware isn't supported, leaving the old one in place?
>>
>
> Can this be done? Can one abort a package installation from a %pre 
> script?
you can exit with an error but...


>
> Even if it is possible, how would one handle deps in a yum 
> transaction? nvidia-x11-drv requires kmod-nvidia of the same version 
> and vice versa. If you abort the installation of one, that will affect 
> other packages in the yum transaction and the depsolve resolution is 
> already done at this point and the transaction underway.
... that's a no-no because any error will fail the whole transaction


>
> The more I look at this whole issue the more I see there are no easy 
> solutions.
This approach would need to make all the [pairsof] relevant kmods 
parallel installable and at the end a script would detect the correct 
driver and use alternative to activate it.


>
> Moving forward, I have been writing a utility (nvidia-detect) to 
> detect NVIDIA graphics cards and recommend the appropriate driver. 
> Here is some example output:
Really really nice. That's the first step for the approach above.