Hello! As written in the subject, kde-base/kdeedu-meta depends on kde-base/artikulate which depends on media-libs/qt-gstreamer which is a problem when kde is desired but no gstreamer (-gstreamer use flag). The artikulate ebuild has no dependency on the gstreamer use flag so it may be a hard requirement. If it is so, I would suggest to add a dependency in kdeedu-meta to not pull in artikulate when there is no gstreamer use flag. Otherwise please fix artikulate to honor the flag. I can provide this (simple) patch for the first solution if desired. Thx! P.S.: My lazy workaround for the moment is just to delete the artikulate dependency in kdeedu-meta but this is not a preferred solution.
what is the bug here? "one package depends on other packages". "meta packages pull in things that i don't want". so *don't install those things*. by definition meta packages depend on everything and install nothing.
This is not correct. Please don't set a bug to "RESOLVED" before understanding the problem. Meta packages do not install everything - check kde-meta and many other kde meta packages if you don't believe. They often install things depending on use flags. To answer your question, the bug here is that some ebuild(s) don't honor the -gstreamer use flag. If you set -gstreamer you expect to not get gstreamer silently pulled in by some dependency. Portage has means to inform about or even enforce some flags for some packages if they are really required. So these means should be used here or there are simple means to avoid the undesired dependency as my proposed solution. I doubt that anyone has to be enforced to install gstreamer just because of an minor kde package most people don't need but which is installed because most people install kde-meta and not every single package by hand. Is it now clear where the bug is?
I'm sorry Konstantin, but you're mistaken. kde-base/kdeedut-meta unconditionally depends on kde-base/artikulate. kde-base/artikulate itself has a mandatory build and runtime dependency on media-libs/qt-gstreamer. If you're unhappy with the result the only option for you is to not to install the meta package and select everything that you want to have installed by hand. Also please keep in mind that the purpose of USE flags is to select optional build and runtime behavior - this is obviously not the case for mandatory build time dependencies. Meaning that even with -gestreamer in your use flags atoms are free to pull in gstreamer as DEPEND or RDEPEND. If you do not want to have gstreamer installed, use /etc/portage/package.mask to mask it.
You can also use package.provided, so the PM does not try to update artikulate anymore.
Thank you Matthias, but exactly this unconditional depend in kdeedu-meta is the error/bug/problem (you name it). Following your argumentation you should fix kdegames-meta-4.14.2.ebuild and change the conditional RDEPEND entries opengl? ( $(add_kdebase_dep ksudoku) ) python? ( $(add_kdebase_dep kajongg) ) to be unconditional. So anybody who wants KDE but not opengl or python use flag should not use kde-meta and install all 250 or so kde packages he needs by hand. I think it is clear why this is not a good idea and I think the guys who wrote the kdeedu-meta ebuild (and many others with similar behavior) know exactly what I'm speaking about. Why is gstreamer and artikulate any different than opengl and ksudoku? OK, the package.provided is also a workaround, thank you for the hint. But IMHO it's still a workaround.
(In reply to Konstantin Münning from comment #5) > Thank you Matthias, but exactly this unconditional depend in kdeedu-meta is > the error/bug/problem (you name it). Following your argumentation you should > fix kdegames-meta-4.14.2.ebuild and change the conditional RDEPEND entries > > opengl? ( $(add_kdebase_dep ksudoku) ) > python? ( $(add_kdebase_dep kajongg) ) > > to be unconditional. So anybody who wants KDE but not opengl or python use > flag should not use kde-meta and install all 250 or so kde packages he needs > by hand. I think it is clear why this is not a good idea and I think the > guys who wrote the kdeedu-meta ebuild (and many others with similar > behavior) know exactly what I'm speaking about. Why is gstreamer and > artikulate any different than opengl and ksudoku? The use flags added to the meta packages were a "yeld" by the KDE team to users. For years there were no use flags in the meta packages as we've always claimed that they were meant to install all packages in a tarball. Since the old days, the tarballs have been split by upstream and a few cases have showed up where it made sense to have a use flag. Since the old days, we've been telling users that the alternative they should be looking for are "sets". In this particular case, even though it makes perfect sense to you to have a way to not install gstreamer, it doesn't make any sense for the kde team to support that.
(In reply to Manuel Rüger from comment #4) > You can also use package.provided, so the PM does not try to update > artikulate anymore. Rüdiger, how do you mean to use package.provided? It is part of /usr/portage meaning it is updated on every sync - I would loose all my settings if I change some file there. I found nothing in the manual pages how to add a package.provided in /etc/portage so the only Idea I have currently would be to add an own repo bringing its own package.provided. I'm just not sure this would work this way. Could you please explain your idea?
> The use flags added to the meta packages were a "yeld" by the KDE team to > users. For years there were no use flags in the meta packages as we've > always claimed that they were meant to install all packages in a tarball. > Since the old days, the tarballs have been split by upstream and a few cases > have showed up where it made sense to have a use flag. Since the old days, > we've been telling users that the alternative they should be looking for are > "sets". > In this particular case, even though it makes perfect sense to you to have a > way to not install gstreamer, it doesn't make any sense for the kde team to > support that. Hmm, I'm using Gentoo for over a decade now and I don't remember the evolution of meta packages but it seems to me as the approach to enforce the bad things of a tarball is quite contrary to the idea of Gentoo to be highly customizable. So adding use flags even to meta packages makes perfectly sense for me to create something better than a tarball but still as convenient. When you speak about "sets", what set are you tinking of? There is no set @kde or so in portage so far I know. By the way, changing the line in the ebuild to gstreamer? ( $(add_kdebase_dep artikulate) ) would has been much less effort than half of this discussion and unequally helpful ;-). I don't see where this would be challenging for the kde team as it requires virtually no support. P.S.: An excerpt from the official Gentoo philosophy to think about: "If the tool forces the user to do things a particular way, then the tool is working against, rather than for, the user. We have all experienced situations where tools seem to be imposing their respective wills on us. This is backwards, and contrary to the Gentoo philosophy."
I know using USE flags like this is *technically* incorrect, but we should still use them until we have runtime-switchable USE flags. We have no other way to implement this often-requested functionality, and refusing to do it on a technicality (I've yet to hear of any actual negative with meta packages) is just giving users the middle finger.
Thank you Michael. Could you please explain why having use flags in meta ebuilds is technically incorrect? As of my technical understanding I see no reason why they should be banned there, they work the same way as they do in other ebuilds. Having the meta ebuild pulling in only the needed/required stuff is a superb feature. Where is the downside?
Changing a USE flag on a package requires rebuilding it. For packages which have an optional dependency that is purely runtime (eg. provide extra feature foo if /usr/bin/bar is available), the policy is to print a message to inform the user instead of adding a USE flag that doesn't actually affect the contents of the package. This applies (on paper) to meta packages as well, however the cost of rebuilding a meta package is almost zero so I believe benefits to the user outweigh the cost of it being technically wrong.
(In reply to Michael Palimaka (kensington) from comment #9) > I know using USE flags like this is *technically* incorrect, but we should > still use them until we have runtime-switchable USE flags. We have no other > way to implement this often-requested functionality, and refusing to do it > on a technicality (I've yet to hear of any actual negative with meta > packages) is just giving users the middle finger. I strongly disagree with your qualification of not adding use flags to meta packages being the same as telling users to go away. The 2 main reasons for not adding it in the past where: 1. being technically wrong (as you've explained) 2. If we were to do it, we would risk having to add tenths and more use flags to each meta package - which is a burden to the maintainers BTW, that's the same reason why we refused to add use flags for optional run-time dependencies for packages like quanta that had many, *many* optional run-time dependencies.
(In reply to Jorge Manuel B. S. Vicetto from comment #12) > I strongly disagree with your qualification of not adding use flags to meta > packages being the same as telling users to go away. > The 2 main reasons for not adding it in the past where: > 1. being technically wrong (as you've explained) > 2. If we were to do it, we would risk having to add tenths and more use > flags to each meta package - which is a burden to the maintainers > > BTW, that's the same reason why we refused to add use flags for optional > run-time dependencies for packages like quanta that had many, *many* > optional run-time dependencies. I perfectly understand the attempt to not overburden the maintainers but what you are telling here is largely overshooting what we are discussing and what I was speaking about. I never meant adding use flags for all possible run-time dependencies. This really does not make sense. For regular packages, as long as it is a dynamic run-time dependency meaning it does not affect the compile process, no use flag is necessary. For meta packages, as long as the pulled-in packages do not enforce any libraries/features for which use flags already exist (alsa, opengl, gstreamer, ...) no use flags are needed. The basic rule for meta packages could be condensed to "no extra use flags should be introduced but existing flags should be honored". I think this is reasonable, maintainable and in fact is often done already. Comments welcome.
As the bug is not invalid but devs are refusing to care and prefer to force anyone using KDE to install gstreamer even if they don't want or use artukulate, wontfix resolution seems to be more appropriate to me.
