$ qlist x11-drivers/nvidia-drivers | grep nvidia-settings /etc/X11/xinit/xinitrc.d/95-nvidia-settings /usr/share/man/man1/nvidia-settings.1.xz /opt/bin/nvidia-settings Thses files should not be installed by the driver package
Well, why not add a optional useflag that removes these files? I found the previous separation into media-video/nvidia-settings and x11-drivers/nvidia-drivers nonsensical. That led to the different versions of settings and drivers installed, this is unnecessarily confusing. Who knows what problems occured in the past, only because of this nonsensical seperation...
(In reply to Frank Krömmelbein from comment #1) > Well, why not add a optional useflag that removes these files? USE=tools installs it. That shouldn't happen. > > I found the previous separation into media-video/nvidia-settings > and x11-drivers/nvidia-drivers nonsensical. > Who knows what problems occured in the past, only because of this > nonsensical seperation... there seperation allows the user to compile the settings util. Whereas the driver package installs some binary version.
(In reply to Justin Lecher from comment #2) > (In reply to Frank Krömmelbein from comment #1) > > Well, why not add a optional useflag that removes these files? > > USE=tools installs it. That shouldn't happen. > > > > > I found the previous separation into media-video/nvidia-settings > > and x11-drivers/nvidia-drivers nonsensical. > > > Who knows what problems occured in the past, only because of this > > nonsensical seperation... > > there seperation allows the user to compile the settings util. Whereas the > driver package installs some binary version. Sorry yes you are right. Just removed media-video/nvidia-settings.
(In reply to Justin Lecher from comment #0) > Thses files should not be installed by the driver package Why?
(In reply to Jeroen Roovers from comment #4) > (In reply to Justin Lecher from comment #0) > > Thses files should not be installed by the driver package > > Why? Because we have a package which allows compilation from source. The driver package installs the binary. The first is the gentoo way which we should follow. We could merge the nvidia-settings package into the driver package so that the versions get matched.
(In reply to Justin Lecher from comment #5) > (In reply to Jeroen Roovers from comment #4) > > (In reply to Justin Lecher from comment #0) > > > Thses files should not be installed by the driver package > > > > Why? > > Because we have a package which allows compilation from source. Only for x11-drivers/nvidia-drivers-3*. > The driver package installs the binary. Only for >x11-drivers/nvidia-drivers-3*. > The first is the gentoo way which we should follow. What's a Gentoo Way? Maybe you're thinking of x11-drivers/xf86-video-nouveau? No, you still haven't said why. The handwaving isn't helping. > We could merge the nvidia-settings package into the driver package > so that the versions get matched. We've been there before, for exactly the kinds of reasons you're not arguing right now, and we're still stuck with separate packages because of that, which is a problem because the media-video/nvidia-settings people think there is One Major Version instead of 4-5 branches to support. I could argue media-video/nvidia-settings should go away for the same stupid reasons you failed to mention.
(In reply to Justin Lecher from comment #5) > We could merge the nvidia-settings package into the driver package > so that the versions get matched. Oh, I must note that you're contradicting the Summary here. Which?
You are installing a binary which is provided by upstream instead of compiling the sources. Please do that by either depending on the source package or merging it into this one. There is no reason to install the binary or am I wrong?
You are wrong. Please reopen this bug report when media-video/nvidia-settings supports all the branches that x11-drivers/nvidia-drivers supports.
(In reply to Jeroen Roovers from comment #9) > You are wrong. So what is it then? > Please reopen this bug report when > media-video/nvidia-settings supports all the branches that > x11-drivers/nvidia-drivers supports. Some aren't supported anymore. How about go forward and starting with 331.20 or the next release?
(In reply to Justin Lecher from comment #10) > Some aren't supported anymore. By whom? Nvidia ships nvidia-settings for every supported branch, neatly packed in binary form with the binary driver, supporting the features that the binary driver supports. Who isn't supporting what? > How about go forward and starting with 331.20 or the next release? So depending on the graphics card you happen to have, you want to install either x11-drivers/nvidia-drivers[tools] or media-video/nvidia-settings with x11-drivers/nvidia-drivers[-tools]? nvidia-drivers is the /only/ package that actually uses the nvidia-settings tools. It doesn't matter at all that Nvidia releases nvidia-settings under the GPL - what matters is that Nvidia ships tools that have been tested with the driver in question. For example: if you have a graphics card which is only supported by the 319.82 driver (as 331.20 is older) you might find that the packaged binary tools work with that driver and with your graphics card, and you might very well find that the "latest" nvidia-settings does not. Now stop reopening this bug report.
(In reply to Jeroen Roovers from comment #11) > (In reply to Justin Lecher from comment #10) > > Some aren't supported anymore. > > By whom? Nvidia ships nvidia-settings for every supported branch, neatly > packed in binary form with the binary driver, supporting the features that > the binary driver supports. Who isn't supporting what? Nvidia doesn't provide the tarball anymore. > > > How about go forward and starting with 331.20 or the next release? > > So depending on the graphics card you happen to have, you want to install > either x11-drivers/nvidia-drivers[tools] or media-video/nvidia-settings with > x11-drivers/nvidia-drivers[-tools]? What is the valid reason to install the binary application instead of compiling it from source? We are a source based distribution and by that we always try to compile as much as possible. So what is the reason to not do this here? > nvidia-drivers is the /only/ package that actually uses the nvidia-settings > tools. It doesn't matter at all that Nvidia releases nvidia-settings under > the GPL - what matters is that Nvidia ships tools that have been tested with > the driver in question. So we should merge the settings tool into this package instead of having a separate one. And again, as source and not as binary. > > For example: if you have a graphics card which is only supported by the > 319.82 driver (as 331.20 is older) you might find that the packaged binary > tools work with that driver and with your graphics card, and you might very > well find that the "latest" nvidia-settings does not. > That's true. We really need to make sure that drivers and tools are matching here. > Now stop reopening this bug report. I do open this report as long as I think it is unfixed and valid. Perhaps you should stop closing it before we reach a consensus.
Maybe someone out there can come up with non-technical reasons that make as much sense as the technical ones?
(In reply to Jeroen Roovers from comment #11) > nvidia-drivers is the /only/ package that actually uses the nvidia-settings > tools. equery d nvidia-settings * These packages depend on nvidia-settings: app-admin/conky-1.9.0-r2 (nvidia ? media-video/nvidia-settings)
(In reply to poncho from comment #14) > (In reply to Jeroen Roovers from comment #11) > > nvidia-drivers is the /only/ package that actually uses the nvidia-settings > > tools. > > equery d nvidia-settings > * These packages depend on nvidia-settings: > app-admin/conky-1.9.0-r2 (nvidia ? media-video/nvidia-settings) That uses a single file from media-video/nvidia-settings: /usr/include/NVCtrl/NVCtrlLib.h The binary executable `nvidia-settings' and other tools have nothing to do with that.
Why is comrel here? this is a QA problem
(In reply to Jeroen Roovers from comment #15) > The binary executable `nvidia-settings' and other tools have nothing to do > with that. Jereon, let's bring this to a productive solution. The original reason I filed this bug, was that I wasn't aware that I have the same application installed two times, which are shadowing each other. Your valid point is that with installing the binary from the drivers package we can really guarantee that versions and functionality are matching to the drivers. I masked USE=tools in nvidia-settings now. So we avoid the shadowing of the tools. Please add tools? ( media-video/nvidia-settings ) to nvidia-drivers.
(In reply to Justin Lecher from comment #17) > (In reply to Jeroen Roovers from comment #15) > > The binary executable `nvidia-settings' and other tools have nothing to do > > with that. > > Jereon, Please at the very least get the names right. > The original reason I filed this bug, was that I wasn't aware that I have > the same application installed two times, which are shadowing each other. No, you *were* aware that there you had two similar binary executables installed. Nothing at all suggests that they are the same. Nvidia has thrown the FOSS community a PR bone by releasing nvidia-settings under an open source license (which is odd because the kernel driver isn't), but it is itself not bound by that license and it can ship a closed source binary executable called `nvidia-settings' that does not match the open source version (which is usually released after the closed-source version), and nothing guarantees that they are the same thing. > Your valid point is that with installing the binary from the drivers package > we can really guarantee that versions and functionality are matching to the > drivers. And you're not arguing against that. > I masked USE=tools in nvidia-settings now. So we avoid the shadowing of the > tools. That doesn't make sense either. > Please add > > tools? ( media-video/nvidia-settings ) > > to nvidia-drivers. I told you I am not going to do it and you haven't told me why I should do it. I'd close this again as WONTFIX and I could provide many more technical reasons why, but you would probably just reopen it and continue with the handwaving. So I'll just leave you sitting here with an open bug report, OK?
(In reply to Jeroen Roovers from comment #18) > No, you *were* aware that there you had two similar binary executables > installed. Nothing at all suggests that they are the same. So tell me how do you want to judge what I am aware of or not? > > Nvidia has thrown the FOSS community a PR bone by releasing nvidia-settings > under an open source license (which is odd because the kernel driver isn't), > but it is itself not bound by that license and it can ship a closed source > binary executable called `nvidia-settings' that does not match the open > source version (which is usually released after the closed-source version), > and nothing guarantees that they are the same thing. I don't think that most of the users know that. We should make this clear to them. > > > Your valid point is that with installing the binary from the drivers package > > we can really guarantee that versions and functionality are matching to the > > drivers. > > And you're not arguing against that. I would but this seems to be an acceptable solution. It makes some sense what you said about nvidias inconsequent handling of closed vs opensource code. > > > I masked USE=tools in nvidia-settings now. So we avoid the shadowing of the > > tools. > > That doesn't make sense either. Doesn't make sense? Try to think about it. You will get it. > > > Please add > > > > tools? ( media-video/nvidia-settings ) That's of course is not what I meant. tools? ( !media-video/nvidia-settings ) that way it makes more sense.
(In reply to Justin Lecher from comment #19) > That's of course is not what I meant. > > tools? ( !media-video/nvidia-settings ) > > that way it makes more sense. Why should they block? /etc/X11/xinit/xinitrc.d/95-nvidia-settings already uses the correct one, and people are free to play with the open source version for all I care, and PATH should usually search /opt/bin before /usr/bin, so nothing could possibly go wrong here.
/usr/share/doc/nvidia-drivers-331.38/html/installedcomponents.html mentions /usr/bin/nvidia-settings but that's about it.
[QA] (In reply to Justin Lecher from comment #17) > Your valid point is that with installing the binary from the drivers package > we can really guarantee that versions and functionality are matching to the > drivers. Blockers to limit versions can guarantee this as well. > I masked USE=tools in nvidia-settings now. So we avoid the shadowing of the > tools. A blocker to avoid installing both at the same time is a good idea to avoid confusion, double installation; as well as let the user better know which one in installed as well as make sure that bugs get filed with the right package. We for example wouldn't want that a bug due to compiling the source-based package would end up upstream whereas it could in fact be a problem with our toolchain or one of the libraries involved. > Please add > > tools? ( media-video/nvidia-settings ) > > to nvidia-drivers. This is uncommon to do; this makes sense if nvidia-drivers would actually use it, but it doesn't really do that apart form installing it itself. So, this is quite similar to the way plugins work in ebuilds; those are usually advertised to the user through the means of pkg_postinst. Which we already have here... The QA team is discussing this and will soon take a vote on this. Currently, the options as two of us see it: (1) do nothing (2) stop installing NVIDIA's binary settings (3) merge them, which means building it from source instead of binary (4) split of NVIDIA's binary settings to media-video/nvidia-settings-bin The former three don't make everyone (you two, NVIDIA, users, ...) happy at once; so, I am wondering if option (4) might be of interest here. That way nvidia-drivers installs just the drivers, and the user can choose between installing nvidia-settings and nvidia-settings-bin as the user sees fit. This works if pkg_postinst presents these choices (which is a small adjustment), you drop the tools USE flag (it becomes useless), nvidia-settings{,-bin} block each other (easy), nvidia-drivers and/or nvidia-settings block incompatible versions between drivers and settings (up to you I guess, encouraged though). Furthermore, as the -bin suffix is often used for Gentoo-build binaries, the install should probably make clear thees are provided by NVIDIA instead to avoid confusion; especially when a source-based package is available. The alternative is to name the source based package media-video/gentoo-nvidia-settings; but that sounds rather odd to me, and I guess there are some licensing considerations... Note that QA hasn't decided on anything yet as most of us aren't even around right now, I'm just giving a heads up as to avoid talking and deciding past each other; early thoughts and feedback regarding these considerations are welcome. (In reply to Jeroen Roovers from comment #18) > Nvidia has thrown the FOSS community a PR bone by releasing nvidia-settings > under an open source license (which is odd because the kernel driver isn't), > but it is itself not bound by that license and it can ship a closed source > binary executable called `nvidia-settings' that does not match the open > source version (which is usually released after the closed-source version), > and nothing guarantees that they are the same thing. If they get to live side by side, I think users should be made aware of this matter; as usually is with NVIDIA, the binary form gets preference. Users that want to do things from source usually keep sitting waiting wishing for things... (In reply to Justin Lecher from comment #19) > I don't think that most of the users know that. We should make this clear to > them. +1 (see above) > > > Your valid point is that with installing the binary from the drivers package > > > we can really guarantee that versions and functionality are matching to the > > > drivers. > > > > And you're not arguing against that. > > I would but this seems to be an acceptable solution. It makes some sense > what you said about nvidias inconsequent handling of closed vs opensource > code. > > > > > > Please add > > > > > > tools? ( media-video/nvidia-settings ) > > That's of course is not what I meant. > > tools? ( !media-video/nvidia-settings ) > > that way it makes more sense. That's something I don't think Jer would oppose to; I'm confused now, but do these last two responses from you mean that besides having this block added you don't have a problem with this anymore? (Though, QA might still want to fix it)
(In reply to Jeroen Roovers from comment #20) > (In reply to Justin Lecher from comment #19) > > That's of course is not what I meant. > > > > tools? ( !media-video/nvidia-settings ) > > > > that way it makes more sense. > > Why should they block? > > /etc/X11/xinit/xinitrc.d/95-nvidia-settings already uses the correct one, > and people are free to play with the open source version for all I care, and > PATH should usually search /opt/bin before /usr/bin, so nothing could > possibly go wrong here. Users can still file bugs against the wrong package or even upstream regardless; having quite similar stuff installed twice, where only one of both gets used, feels like an odd setup to have for an user. Actually, if I think about this we actually have this in the Portage tree (eg. *office-bin); at the very least jlec might want to make clear how to file bugs against his package for the open-source version in pkg_postinst (and to not file them against the drivers or upstream until asked explicitly by jlec).
It's my opinion that media-video/nvidia-settings should be removed from the tree if your intention is to avoid confusion. The current maintenance policy is probably the most confusing part for users because the best version doesn't work with every branch of x11-drivers/nvidia-drivers, so it's pointless to offer it at all. It's my opinion that I should be allowed to close this bug report as WONTFIX since nothing needs to change in x11-drivers/nvidia-drivers - it's working fine and only media-video/nvidia-settings is confusing, apparently even to its maintainer. If not changing x11-drivers/nvidia-drivers is now the intention of this bug report, then why has the Summary not been changed accordingly? As it stands, it's a WONTFIX.
(In reply to Jeroen Roovers from comment #24) > It's my opinion that media-video/nvidia-settings should be removed from the > tree if your intention is to avoid confusion. The current maintenance policy > is probably the most confusing part for users because the best version > doesn't work with every branch of x11-drivers/nvidia-drivers, so it's > pointless to offer it at all. This is what I prefer, too, as you are right, we should follow the direction NVIDIA dictats. So let's WONTFIX that and last rite media-video/nvidia-settings. What should we do about the other files in media-video/nvidia-settings?
Er, so now media-video/nvidia-settings blocks =x11-drivers/nvidia-drivers-3*[tools] which would normally allow comparing both versions of the binary executable nvidia-settings directly for all kinds of useful purposes. Can we revert that?
(In reply to Jeroen Roovers from comment #26) > Er, so now media-video/nvidia-settings blocks > =x11-drivers/nvidia-drivers-3*[tools] which would normally allow comparing > both versions of the binary executable nvidia-settings directly for all > kinds of useful purposes. Can we revert that? What would be a useful purposes? I cannot see any. But feel free to do what ever you think is the best. I dropped myself as maintainer yesterday, so I won't stop you from anything anymore.
*** Bug 498176 has been marked as a duplicate of this bug. ***
