trying to emerge =media-video/nvidia-settings-295.20 with installed =x11-drivers/nvidia-drivers-295.20-r1 * Detected file collision(s): * * /usr/share/pixmaps/nvidia-settings.png * /usr/share/man/man1/nvidia-settings.1.bz2 * /usr/bin/nvidia-settings * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * x11-drivers/nvidia-drivers-295.20-r1 * /usr/bin/nvidia-settings * /usr/share/man/man1/nvidia-settings.1.bz2 * /usr/share/pixmaps/nvidia-settings.png * * Package 'media-video/nvidia-settings-295.20' NOT merged due to file * collisions. If necessary, refer to your elog messages for the whole * content of the above message.
Same here
Confirmed on x86
Confirmed on amd64.
Also on amd64. I put into my package.mask: =x11-drivers/nvidia-drivers-295.20-r1 =media-video/nvidia-settings-295.20 This downgraded to x11-drivers/nvidia-drivers-290.10-r2 and media-video/nvidia-settings-290.10 as expected. BUT I had foolishly unmerged media-video/nvidia-settings while trying to figure this out and I had the same problem on trying to emerge media-video/nvidia-settings-290.10: *Detected file collision(s): * * /usr/share/pixmaps/nvidia-settings.png * /usr/share/man/man1/nvidia-settings.1.bz2 * /usr/bin/nvidia-settings * *Searching all installed packages for file collisions... * *Press Ctrl-C to Stop * *x11-drivers/nvidia-drivers-290.10-r2 * /usr/bin/nvidia-settings * /usr/share/man/man1/nvidia-settings.1.bz2 * /usr/share/pixmaps/nvidia-settings.png * *Package 'media-video/nvidia-settings-290.10' NOT merged due to file *collisions. If necessary, refer to your elog messages for the whole *content of the above message. (Used a COLLISION_IGNORE line in my make.conf to work around, but not sure why it's a problem now when I'm pretty sure those were the versions I was using before I tried to upgrade this morning.)
Also suffering from this on amd64.
Problem does not occur when x11-drivers/nvidia-drivers is emerged with USE="-gtk", which, according to the ebuild, is the reason of x11-drivers/nvidia-drivers installing the colliding files. So a quick fix might be to make media-video/nvidia-settings depend on x11-drivers/nvidia-drivers[-gtk].
(In reply to comment #6) > Problem does not occur when x11-drivers/nvidia-drivers is emerged with > USE="-gtk", which, according to the ebuild, is the reason of > x11-drivers/nvidia-drivers installing the colliding files. > > So a quick fix might be to make media-video/nvidia-settings depend on > x11-drivers/nvidia-drivers[-gtk]. There's some conflicting information in the nvidia-drivers ebuild: * USE=gtk controls whether the nvidia-settings application * is installed. If you would like to use it, enable that * flag and re-emerge this ebuild. media-video/nvidia-settings * no longer installs nvidia-settings but only installs the * associated user space libraries. Also, if I reemerge nvidia-drivers as you propose, nvidia-settings is mo longer pulled in as a dependency, so it's not really a fix unless you want to emerge nvidia-settings by hand.
This is very confusing: "media-video/nvidia-settings no longer installs nvidia-settings" So you have a package called "nvidia-settings" which does not install nvidia-settings :-/ Perhaps a name change is in order (something like nvidia-settings-lib maybe.) Furthermore, the USE flag is called "gtk" while it should probably be "nvidia-settings".
*** Bug 404473 has been marked as a duplicate of this bug. ***
Just wanted to add that I have same issue on 2 systems using nvidia.
Same here on ~amd64
Confirmed ~amd64
*** Bug 405033 has been marked as a duplicate of this bug. ***
same here on x86 Given that the nvidia-drivers ebuild is correct with - on one side depending on nvidia-settings like "gtk? ( media-video/nvidia-settings)" and - on the other side install the conflicting files using the same use-flag "if use gtk; then dobin ${NV_EXEC}/nvidia-settings || die; fi" it seem to me, that a matching nvidia-settings ebuild is just missing, that mirrors the desired change described here: * USE=gtk controls whether the nvidia-settings application * is installed. If you would like to use it, enable that * flag and re-emerge this ebuild. media-video/nvidia-settings * no longer installs nvidia-settings but only installs the * associated user space libraries. In my tree there is noe nvidia-settings ebuild, that does not install nvidia-settings.
media-video/nvidia-settings-295.20 has been hardmasked, media-video/nvidia-settings-290.10 now installs fine (as a dependency). Just a temporary fix I hope.
Isn't it better to stop installing the pre-built nvidia-settings that comes with -drivers and keep installing the version compiled from source in the nvidia-settings package?
(In reply to comment #16) > Isn't it better to stop installing the pre-built nvidia-settings that comes > with -drivers and keep installing the version compiled from source in the > nvidia-settings package? This is my thinking exactly. When I installed both the nvidia-drivers-295.20-r1 and nvidia-settings-295.20 (unmasked from my overlay) I just manually allowed nvidia-settings to overwrite the three colliding files. I found that on my older ~amd64 laptop with a Geforce7950 graphics card the battery life was much better with the newer nvidia-settings vs the older one unmasked in portage. All of the newer nvidia settings applets have a button that allows the card to be placed in either "adaptive" mode for dynamic power savings or "prefer maximum performance" which locks the clocks to their highest rate for gaming etc. This feature doesn't function as well on the older nvidia-settings control applets. Using older versions shortens my battery up-time by up to a half hour. This is a big deal when you've got an older 17inch power hog that barely gets 2 hours on a charge, when PM is properly working on a good day. So if there is a way to work this out between the maintainers of the different nvidia drivers/settings ebuilds so that the compiled version of the colliding files from nvidia-settings are used instead of the precompiled ones from the nvidia-drivers package, I think would be the preferrable way to go. Ciao
The plan is: nvidia-drivers installs the nvidia-settings bin into /opt and as soon as it is done we'll restore the old nvidia-settings ebuild to install both, the lib as well as nvidia-settings itself. It will take some time till this is done but it will happen ;)
media-video/nvidia-settings-295.20 has just been successfully emerged here, with x11-drivers/nvidia-drivers-295.20-r1 installed. No collisions anymore (at least none that were reported). Works for me.
nvidia-settings installs nvidia-settings again and there should be no file collisions anymore
Does not work for me. media-video/nvidia-settings-295.20 was just marked stable, so: # emerge -Dpu world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] media-video/nvidia-settings-295.20 [260.19.29] USE="-examples%" 0 kB Total: 1 package (1 upgrade), Size of downloads: 0 kB # emerge -Du world [...] >>> Emerging (1 of 1) media-video/nvidia-settings-295.20 * nvidia-settings-295.20.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking nvidia-settings-295.20.tar.bz2 to /var/tmp/portage/media-video/nvidia-settings-295.20/work >>> Source unpacked in /var/tmp/portage/media-video/nvidia-settings-295.20/work >>> Preparing source in /var/tmp/portage/media-video/nvidia-settings-295.20/work/nvidia-settings-295.20 ... * Applying 0001-Makefile-improvements.patch ... [ ok ] * Applying 0002-Build-libNVCtrl-with-PIC.patch ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/media-video/nvidia-settings-295.20/work/nvidia-settings-295.20 ... >>> Source configured. >>> Compiling source in /var/tmp/portage/media-video/nvidia-settings-295.20/work/nvidia-settings-295.20 ... * Building libXNVCtrl... make -j5 -C src/libXNVCtrl/ clean make: Entering directory `/var/tmp/portage/media-video/nvidia-settings-295.20/work/nvidia-settings-295.20/src/libXNVCtrl' rm -f libXNVCtrl.a *.o make: Leaving directory `/var/tmp/portage/media-video/nvidia-settings-295.20/work/nvidia-settings-295.20/src/libXNVCtrl' make -j5 -C src/libXNVCtrl/ CC=x86_64-pc-linux-gnu-gcc RANLIB=x86_64-pc-linux-gnu-ranlib libXNVCtrl.a make: Entering directory `/var/tmp/portage/media-video/nvidia-settings-295.20/work/nvidia-settings-295.20/src/libXNVCtrl' x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fPIC -c -o NVCtrl.o NVCtrl.c ar rv libXNVCtrl.a NVCtrl.o ar: creating libXNVCtrl.a a - NVCtrl.o x86_64-pc-linux-gnu-ranlib libXNVCtrl.a rm NVCtrl.o make: Leaving directory `/var/tmp/portage/media-video/nvidia-settings-295.20/work/nvidia-settings-295.20/src/libXNVCtrl' * Building nvidia-settings... [...] >>> Source compiled. >>> Test phase [not enabled]: media-video/nvidia-settings-295.20 >>> Install nvidia-settings-295.20 into /var/tmp/portage/media-video/nvidia-settings-295.20/image/ category media-video make -j5 DESTDIR=/var/tmp/portage/media-video/nvidia-settings-295.20/image/ PREFIX=/usr install mkdir -p /var/tmp/portage/media-video/nvidia-settings-295.20/image//usr/bin mkdir -p /var/tmp/portage/media-video/nvidia-settings-295.20/image//usr/share/man/man1 install -m 755 _out/Linux_x86_64/nvidia-settings /var/tmp/portage/media-video/nvidia-settings-295.20/image//usr/bin/nvidia-settings install -m 755 _out/Linux_x86_64/nvidia-settings.1 /var/tmp/portage/media-video/nvidia-settings-295.20/image//usr/share/man/man1/nvidia-settings.1 >>> Completed installing nvidia-settings-295.20 into /var/tmp/portage/media-video/nvidia-settings-295.20/image/ strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment -R .GCC.command.line usr/bin/nvidia-settings usr/lib64/libXNVCtrl.a ecompressdir: bzip2 -9 /usr/share/doc >>> Installing (1 of 1) media-video/nvidia-settings-295.20 * checking 8 files for package collisions * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / <filename>` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at http://bugs.gentoo.org unless you report exactly which * two packages install the same file(s). Once again, please do NOT file * a bug report unless you have completely understood the above message. * * Detected file collision(s): * * /usr/bin/nvidia-settings * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * x11-drivers/nvidia-drivers-295.20-r1 * /usr/bin/nvidia-settings * * Package 'media-video/nvidia-settings-295.20' NOT merged due to file * collisions. If necessary, refer to your elog messages for the whole * content of the above message. >>> Failed to install media-video/nvidia-settings-295.20, Log file: >>> '/var/log/portage/media-video:nvidia-settings-295.20:20120503-111801.log'
Indeed, amd64 here with the exact same issue (file collision on /usr/bin/nvidia-settings) after a full tree resync and multiple rebuilds of both =nvidia-drivers-295.20-r1 and =nvidia-settings-295.20; trying to emerge =nvidia-settings-295.20 fails.
Should I file a new bug or will someone reopen this?
There's nothing to do here from the nvidia-drivers side. The old versions are staying how they were and the new versions have changes to allow you to replace pieces with nvidia-settings. We've discussed this on IRC a few times.
What is the purpose of media-video/nvidia-settings? Why is it needed? Doesn't the nvidia-settings tools that comes with the driver work?
(In reply to comment #24) > There's nothing to do here from the nvidia-drivers side. Maybe something needs to be done on the nvidia-settings side then, because, if it won't install, it is obviously broken. > The old versions are staying how they were and the new versions have changes to > allow you to replace pieces with nvidia-settings. Perhaps nvidia-settings should require specific versions of nvidia-drivers then. > We've discussed this on IRC a few times. Somehow, I didn't get an invitation for that.
How can you say that it should be fine (when nvidia-settings now installs nvidia-settings binary)? Dependencies in both packages are plain broken! Situation is as follows: nvidia-drivers-290.10-r2.ebuild nvidia-drivers-290.10.ebuild nvidia-drivers-295.20-r1.ebuild - when USE=gtk, install nvidia-setting binary - gtk? ( media-video/nvidia-settings ) - !<media-video/nvidia-settings-256.52 nvidia-drivers-295.40.ebuild nvidia-drivers-295.49.ebuild - when USE=gtk, install nvidia-setting binary - gtk? ( media-video/nvidia-settings ) nvidia-settings-260.19.29.ebuild - doesn't install nvidia-setting binary at all (just libXNVCtrt) And this would be fine but... This is when things started to break dependency-wise): nvidia-settings-275.43.ebuild nvidia-settings-290.10.ebuild nvidia-settings-295.20.ebuild nvidia-settings-295.40.ebuild - started to install nvidia-settings binary - no block on nvidia-drivers[gtk] at all! How can anyone expect it to work? What is target plan? 1 or 2? 1. nvidia-drivers[gtk] provides nvidia-setting binary and nvidia-settings provides nvidia-settings binary? If so, then: 1.1 nvidia-drivers should have "gtk? ( !media-video/nvidia-settings )" in RDEPEND 2.2 nvidia-settings should have "!nvidia-drivers/nvidia-settings[gtk]" in RDEPEND. Mutual blocks. Currently dependencty logic is reversed (nvidia-drivers pulls nvidia-settings providing binary and wonders why there's file collision...) 2. nvidia-drivers[gtk] provides nvidia-setting binary and nvidia-settings only provides libXNVCtrt library? If so, then: 2.1 nvidia-drivers shouldn't have any dependency references to nvidia-setting at all 2.2 nvidia-settings should be renamed to libXNVCtrl and shouldn't provide nvidia-settings binary anymore Dor dependency simplicity I would suggest 2) (as it seems there's problem with implementing 1) properly. Should I do it?
(In reply to comment #27) > 2.2 nvidia-settings should have "!nvidia-drivers/nvidia-settings[gtk]" > in RDEPEND. Errata: 2.2 nvidia-settings should have "!x11-drivers/nvidia-drivers[gtk]" in RDEPEND.
This has already been fixed in nvidia-drivers-295.49. It does not pull nvidia-settings. So now it's up to the nvidia-settings maintainer to do a block on "nvidia-drivers[tools]".
(In reply to comment #24) > There's nothing to do here from the nvidia-drivers side. The old versions > are staying how they were and the new versions have changes to allow you to > replace pieces with nvidia-settings. > > We've discussed this on IRC a few times. 2012-04-11 20:31:07 @Cardoe idl0r: not sure if you've messed with nvidia-settings lately 2012-04-11 20:31:17 @Cardoe idl0r: But you should see that everything has been moved aside. So that was the "ok" to me, to restore the initial functionality of the nvidia-settings ebuild. Unfortunately I did not verify whether *all* nvidia-drivers ebuilds got the fix.
Created attachment 310881 [details, diff] nvidia-drivers ebuild dependency patch (option 1) See attached patch for nvidia-drivers ebuilds.
Created attachment 310883 [details, diff] nvidia-settings dependency (+consistency) patch (option 1) And respective nvidia-settings dependency fix. For consistency, in nvidia-settings-260.19.29.ebuild case it also enables-back nvidia-setting binary (and ebuild would need to be revbumped, or removed from tree completely).
Hasn't "gtk" been replaced with "tools"?
So just to replace gtk with tools in my both patches.
Created attachment 310885 [details, diff] nvidia-settings dependency (+consistency) patch (option 1) Use tools flag.
Created attachment 310889 [details, diff] nvidia-drivers ebuild dependency patch (option 1) nvidia-drivers updated to use tools everywhere (2xx - driver series). einfo about nvidia-settings also updated.
Created attachment 310891 [details, diff] nvidia-settings dependency fix That one should work as expected.
Getting closer here, but something is still not quite right: First of all, I have uninstalled nvidia-settings (based on advice in the forums). # emerge -p nvidia-drivers These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-drivers/nvidia-drivers-295.20-r1 USE="acpi (multilib) -custom-cflags -gtk*" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB The following USE changes are necessary to proceed: #required by nvidia-drivers (argument) =x11-drivers/nvidia-drivers-295.20-r1 -gtk velocious adobe-flash # less /usr/portage/x11-drivers/nvidia-drivers/nvidia-drivers-295.20-r1.ebuild # emerge -p nvidia-settings These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-drivers/nvidia-drivers-295.20-r1 USE="acpi (multilib) -custom-cflags -gtk*" 0 kB [ebuild N ] media-video/nvidia-settings-295.20 USE="-examples" 0 kB Total: 2 packages (1 new, 1 reinstall), Size of downloads: 0 kB The following USE changes are necessary to proceed: #required by media-video/nvidia-settings-295.20, required by nvidia-settings (argument) =x11-drivers/nvidia-drivers-295.20-r1 -gtk So now nvdia-settings prevents the file collision by demanding -gtk for nvidia-drivers (good), but (if I understand - which is far from a sure thing) nvidia-drivers (with -gtk) no longer requires nvidia-settings AND no longer installs its own binary (not so good). It seeks I can work around this by installing nvidia-settings manually, but I believe that the logic in the relevant ebuilds could use some further improvement.
nvidia-drivers >= 295.33 installs nvidia-settings into /opt the drivers prior don't so either you use the nvidia-settings package, nvidia-drivers[gtk] or nvidia-settings + nvidia-drivers >= 295.33. A minimal useflag for nvidia-settings is on my TODO, to only build/install the library.
(In reply to comment #37) > Created attachment 310891 [details, diff] [details, diff] > nvidia-settings dependency fix > > That one should work as expected. Yeah, if you like making things more complicated than necessary. Good luck with that...
(In reply to comment #40) > (In reply to comment #37) > > Created attachment 310891 [details, diff] [details, diff] [details, diff] > > nvidia-settings dependency fix > > > > That one should work as expected. > > Yeah, if you like making things more complicated than necessary. Good luck > with that... Uhm.. The most recent version of the nvidia-drivers are using "tools", the most recent version of the nvidia-drivers install into /opt so what exactly is wrong and more complicated with my dependency patch?
(In reply to comment #39) > nvidia-drivers >= 295.33 installs nvidia-settings into /opt the drivers > prior don't so either you use the nvidia-settings package, > nvidia-drivers[gtk] or nvidia-settings + nvidia-drivers >= 295.33. > A minimal useflag for nvidia-settings is on my TODO, to only build/install > the library. With nvidia-drivers 295.20-r1, I CAN'T install with the gtk USE flag, because nvidia-settings (with the recent change) won't let me.
(In reply to comment #42) > (In reply to comment #39) > > nvidia-drivers >= 295.33 installs nvidia-settings into /opt the drivers > > prior don't so either you use the nvidia-settings package, > > nvidia-drivers[gtk] or nvidia-settings + nvidia-drivers >= 295.33. > > A minimal useflag for nvidia-settings is on my TODO, to only build/install > > the library. > > With nvidia-drivers 295.20-r1, I CAN'T install with the gtk USE flag, > because nvidia-settings (with the recent change) won't let me. That is the purpose of my dependency fix, otherwise it would collide again because, as I said, only nvidia-settings >= 295.33 installs it into /opt.
> That is the purpose of my dependency fix, otherwise it would collide again > because, as I said, only nvidia-settings >= 295.33 installs it into /opt. Then why not fix ~295.20 instead of leaving it broken by design? Is it really so difficult to just change the few lines that install /usr/bin/nvidia-settings? Since x11-drivers/nvidia-drivers-295.20-r1 is in the tree (and marked stable) it is supposed to be supported. Maybe you should just remove x11-drivers/nvidia-drivers-295.20-r1 immediately. Then you could at least say with a straight face that your "solution" works.
(In reply to comment #44) > > That is the purpose of my dependency fix, otherwise it would collide again > > because, as I said, only nvidia-settings >= 295.33 installs it into /opt. > I meant "only nvidia-settings >= ..." btw. > Then why not fix ~295.20 instead of leaving it broken by design? Is it > really so difficult to just change the few lines that install > /usr/bin/nvidia-settings? Since x11-drivers/nvidia-drivers-295.20-r1 is in > the tree (and marked stable) it is supposed to be supported. Maybe you > should just remove x11-drivers/nvidia-drivers-295.20-r1 immediately. Then > you could at least say with a straight face that your "solution" works. I guess you're referring to nvidia-settings-260.19.29. This is the only one that does not install nvidia-settings itself. For that reason I filed a stable request for 295.20. I can't and won't change 260.19.29 as it is already stable for months. And if you really mean 295.20 then I really don't know what you want me to change. It installs nvidia-settings properly and the dependencies are fine now. If you want to build nvidia-settings "yourself" then use nvidia-settings and nvidia-drivers[-gtk] or >=nvidia-drivers-295.33[tools] and otherwise just nvidia-drivers[tools] or gtk (depending on the version) and don't install nvidia-settings at all.
I've analyzed what's the situation (in comment #27) and provided correct and clean solution to this dependency problem. Hmm, how about using attached patches that use tools instead of gtk USE flag everywhere in 2xx driver series and set deps accordingly and be done with it? But hey, please go on with introducing new flags in certain ebuild versions and keep adding || ( ) dependency variants and !version restrictions nobody is going to be able to track in a future. @throw_away_2002 Did you check those two patches on mine?
(In reply to comment #46) > I've analyzed what's the situation (in comment #27) and provided correct and > clean solution to this dependency problem. > > Hmm, how about using attached patches that use tools instead of gtk USE flag > everywhere in 2xx driver series and set deps accordingly and be done with it? > No. That touches stable ebuilds so that's out of the question. These changes are at the request of the nvidia-settings maintainers and I've very much expressed that changes will only happen on new ebuilds going forward. The recent change to the USE flag was as a result of complaints in #gentoo-dev. Hopefully by the 302.x series we can do away with the churn and get to a happy medium. I've personally removed nvidia-settings from my machines until all this dies down.
(In reply to comment #45) > I guess you're referring to nvidia-settings-260.19.29. This is the only one > that does not install nvidia-settings itself. For that reason I filed a > stable request for 295.20. I can't and won't change 260.19.29 as it is > already stable for months. No, I am referring to the combination (both stable) of x11-drivers/nvidia-drivers-295.20-r1 and media-video/nvidia-settings-295.20. As currently, in the tree, there is no way to get nvidia-settings. The gtk USE flag is not allowed, so the settings program from nvidia-drivers in not installed. Further, nvidia-settings is no longer installed (because the gtk USE flag is stripped), so no settings program gets instaled. > And if you really mean 295.20 then I really don't know what you want me to > change. There are a number of sensible alternatives: 1. Modify x11-drivers/nvidia-drivers-295.20-r1 so that the settings program is not installed. I don't believe that such a change is dangerous, but call it -r2 and leave it unstable if you must. 2. Remove x11-drivers/nvidia-drivers-295.20-r1 it from the tree (basically, you are saying it is no longer proprely supported). 3. Change media-video/nvidia-settings-295.20 to require >x11-drivers/nvidia-drivers-295.20-r1 (with a proper einfo). This leaves the user to find a solution, but at least it warns him that something is wrong. Taking away the gtk USE flag by force is really going down the wrong path. (In reply to comment #46) > @throw_away_2002 > Did you check those two patches on mine? I haven't yet, but I will. This is a classic representation of why I use gentoo - it is relatively easy to overcome developer idiocies.
> > @throw_away_2002 > > Did you check those two patches on mine? > > I haven't yet, but I will. This is a classic representation of why I use > gentoo - it is relatively easy to overcome developer idiocies. You'ge going too far. Those are merely technical differences.
(In reply to comment #47) > No. That touches stable ebuilds so that's out of the question. Hmm, since when stable ebuilds are forbidden from receiving dependency fixes and USE flag renames? Package manager handles them well. It may be only maintaner's preference but never a policy.
Since the file-collision(s) itself are fixed I'd like to close this bug. For anything else we/one should open a new bug instead. Any objections?
(In reply to comment #51) > Since the file-collision(s) itself are fixed I'd like to close this bug. > For anything else we/one should open a new bug instead. > Any objections? Since I have finally obtained permission to updated to nvidia-drivers-295.40, this is no longer a problem for me, but I did notice something strange after the upgrade (maybe this is a feature, not a bug): media-video/nvidia-settings-295.20 installs /usr/share/applications/nvidia-settings-nvidia-settings.desktop and x11-drivers/nvidia-drivers-295.40 installs /usr/share/applications/nvidia-settings-opt.desktop So there are two "NVIDIA X Server Settings" items in my menu. This seems wrong, but what do I know?
(In reply to comment #51) > Since the file-collision(s) itself are fixed I'd like to close this bug. > For anything else we/one should open a new bug instead. > Any objections? Yes. This bug is improperly 'fixed'. USE=gtk emerge -1 '='nvidia-drivers-295.40 installs nvidia-drivers executable in /opt/bin and additionally pulls nvidia-setting for no reason whatsoever (which installs another nvidia-settings executable, this time in /usr/bin)
Errata: installs *nvidia-settings* executable in /opt/bin and additionally pulls media-video/nvidia-setting for no reason whatsoever (which installs another nvidia-settings executable, this time in /usr/bin)
So I'll re-assign to the nvidia-drivers maintainer then.
That version isn't in the tree. Use 295.49 (stable) or 295.53 (~arch).
Ok, ... I'll close this bug now as the *actual* issue has been fixed. If there are any further issues then open a new bug.
