Bug 238469 – Split nvidia-drivers into nvidia-legacy-drivers

• Product: Gentoo Linux
• Status: RESOLVED TEST-REQUEST

[Description Roger 2008-09-23 12:50:14 UTC]

I run a shared Portage via NFS here and the only package I'm having problems with is this nvidia-drivers package.  My clients can only utilize the nvidia legacy driver version.  The server can utilize the most recent nvidia-driver version.

This nvidia-driver ebuild is trying to handle 2 to 3 separate driver software packages.

Reproducible: Always

Steps to Reproduce:
1.emerge nvidia-drivers
2.Per exported /usr/portage NFS share, I end up getting one nvidia-drivers package version for all my x86 serves & clients.  Regardless whether or not they require legacy drivers!



Expected Results:  
Recent nvidia h/w gets recent nvidia-drivers.

Old legacy nvidia h/w should get legacy nvidia-drivers.

There is no easy solution to hack around with NFS exports or mount NFS exports to get package keywords or masks situated.  I even use NFS4, but still not making things any easier.  I still end-up having to hand alter files.

Whatever happened to the nvidia-legacy-drivers and nvidia-drivers split a year or more ago?

[Comment 1 Jeroen Roovers (RETIRED) 2008-09-23 13:03:25 UTC]

You should set up different profiles for different systems in a local overlay and (un)mask specific version of nvidia-drivers in those separate profiles.

[Comment 2 Roger 2008-09-26 21:23:50 UTC]

mmm... right. Since I'm only exporting /usr/portage, can separate this into /usr/local/portage.

But I only see it as a temporary hack.

As far as sharing Portage via NFS, there really needs to be a better hierarchy.

/usr/portage == remote portage sync
/usr/local/portage == local networks portage (customizations)
/opt/portage == A boxes immediate local portage for customizations.


If anybody is working with sharing Portage via NFS on their local network (as they well are as it's encouraged to conserve bandwidth when possible), I'm seeing a shortness of network features for Portage to operate in such an environment.

Either of the following needs to be implemented to make this scenario more sound:

1) Structure ebuilds so they do not inter-mangle multiple software packages.  (This is probably the easiest method as it only requires a minor ebuild policy change -- which probably should have been implemented years ago.)

2) Provide masking by $HOSTNAME in /etc/portage files (or elsewhere).  This is probably a better fix and more complaint with the standards of Linux coding but would require a more coding.

Think I've done enough griping on this known issue for the past year or so.  Doesn't seem like anybody is an any agreement with any of it.  If others had some interest but with little time to code, I could probably help code something along.  My current knowledge is with C/BASH, but can easily p/u an already selected Python book from the local library and help-out.

For now, I'll push a /usr/local/portage... but as soon as I start creating ebuilds again and trying to sync my work to all my other local boxes for working on the ebuilds from anywhere with my local network, I'm going to get screwed-up again, as the hierarchy of Portage custom masking not being laid-out to work within a network properly.