On 01/30/2013 09:08 AM, Phil Perry wrote:
We could create a set of dummy packages specific for hardware classes.
For example,
nvidia-6xxx
nvidia-7xxx
...
etc
and then somehow figure out a way to get the correct hardware-specific
dummy package onto users systems (that's the tricky part).
The
On 30/01/13 15:53, Manuel Wolfshant wrote:
On 01/30/2013 03:50 PM, Phil Perry wrote:
I have no idea if you can call 'yum' from within a yum transaction,
but I very much doubt it as the rpm database has to be locked during
the transaction.
You can't. Just like you cannot invoke rpm from rpm scr
On 01/30/2013 03:50 PM, Phil Perry wrote:
On 30/01/13 12:49, John Hodrien wrote:
On Wed, 30 Jan 2013, Nicolas Thierry-Mieg wrote:
ok, so most of the package updates will happen when the "current"
driver
gets updated.
This mitigates the (slight) issue, but only for people with modern
hardware
On 30/01/13 13:05, Phil Perry wrote:
So, to this end, what _can_ we do?
I'm more than willing to reconsider / revisit the idea of echoing a
warning to the console upon package installation/updating that will warn
a user if the version being installed/updated does not support the
detected hardwa
On 30/01/13 12:49, John Hodrien wrote:
On Wed, 30 Jan 2013, Nicolas Thierry-Mieg wrote:
ok, so most of the package updates will happen when the "current" driver
gets updated.
This mitigates the (slight) issue, but only for people with modern
hardware (who use and want the updated "current" driv
On 30.01.2013 13:12, 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.
Well, it was a good chat. :-)
--
Sent from the
On 30/01/13 12:42, Nicolas Thierry-Mieg wrote:
Phil Perry wrote:
On 29/01/13 19:54, Nicolas Thierry-Mieg wrote:
Le 28/01/2013 23:52, Nux! a écrit :
On 28.01.2013 21:26, Lamar Owen wrote:
The pipe-dream, and a 'better than Windows' experience, is a single
package set that covers all legacy ver
On 28/01/13 21:26, Lamar Owen wrote:
On 01/28/2013 02:54 PM, Phil Perry wrote:
On 25/01/13 23:13, Lamar Owen wrote:
On Jan 25, 2013, at 4:03 PM, Nux! wrote:
- why not in cases like this send a Requires for some noarch that
executes a script and does a "yum replace"[1] based on pci id?
How d
On Wed, 30 Jan 2013, Nicolas Thierry-Mieg wrote:
ok, so most of the package updates will happen when the "current" driver
gets updated.
This mitigates the (slight) issue, but only for people with modern
hardware (who use and want the updated "current" driver anyway). Users
who are on a legacy ve
Phil Perry wrote:
On 29/01/13 19:54, Nicolas Thierry-Mieg wrote:
Le 28/01/2013 23:52, Nux! a écrit :
On 28.01.2013 21:26, Lamar Owen wrote:
The pipe-dream, and a 'better than Windows' experience, is a single
package set that covers all legacy versions plus the current version
and leverages ude
On 30.01.2013 11:37, Phil Perry wrote:
My initial thought would be to install all 4 modules in the form of
nvidia-current.ko, nvidia-304.ko etc, and then to use a script to
detect the current hardware, select the correct driver and copy that
driver into place, and finally running depmod. The scri
On 29/01/13 19:54, Nicolas Thierry-Mieg wrote:
Le 28/01/2013 23:52, Nux! a écrit :
On 28.01.2013 21:26, Lamar Owen wrote:
The pipe-dream, and a 'better than Windows' experience, is a single
package set that covers all legacy versions plus the current version
and leverages udev to load the right
12 matches
Mail list logo
