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@wolfy ~]$ ls /usr/lib/sendmail -l
lrwxrwxrwx. 1 root root 30 Jun 7 2011 /usr/lib/sendmail ->
/etc/alternatives/mta-sendmail
[wolfy@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.
_______________________________________________
elrepo mailing list
[email protected]
http://lists.elrepo.org/mailman/listinfo/elrepo
