It would be good, if all of the kde*-meta packages (or meta packages in general) had USE flags, which allows the user to selectively chose, which programs he wants. For example, kdemultimedia-meta installs kmid. If a user does not want/need MIDI support, he either has to install that unwanted package anyway (can you say "cruft"?), or he has to add a line to /etc/portage/profile/package.provided or NOT use this meta package. The last option (not using the meta package) is the *WORST* option to chose. Reason: The user might want all the other packages that this -meta package pulls in, but not just this particular package. Furthermore, in the case of the kde*-meta packages, not using eg. kdemultimedia-meta would mean, that kde-meta is also not usable. This would mean, that the user would have to "manually" emerge all the packages, just because he doesn't want one single package. Not good. And finally, if there were USE flags, users would be able to only install as much as they want. The current "all or nothing" way is not the best and most userfriendly way.
What's wrong with simply uninstalling (emerge -C) the unwanted packages, followed by an emerge --depclean?
(In reply to comment #1) > What's wrong with simply uninstalling (emerge -C) the unwanted packages, > followed by an emerge --depclean? Originally, I was annoyed by getting ppp installed as a dependency of kppp, which is a dependency of kdenetwork-meta. So I uninstalled ppp and kppp. Then I ran "emerge -DuvatN world" (which I do regularly). This emerge run then reinstalled ppp & kppp to satisfy the dependencies of kdenetwork-meta and kde-meta. Now you might say: Don't use kde-meta in the first place. I don't think that this would be a good answer, though. Reason: This would mean, that about 300 packages would manually need to be installed. This defeats the whole point of the split ebuilds, doesn't it? Also, suppose you'd want to install everything of KDE (ie. kde-meta), but not one single package, because you know that you don't use it. How would you solve that (modifying ebuilds is not a good answer *g*)?
(In reply to comment #2) > Also, suppose you'd want to install everything of KDE (ie. kde-meta), but not > one single package, because you know that you don't use it. How would you solve > that (modifying ebuilds is not a good answer *g*)? My preference is also for -meta ebuilds to emerge everything by default, and the user has the choice to leave some stuff out if they so choose. What would accomplish this is (for example) a local USE flag to kdepim-meta called nokppp. DEPEND would contain this: !nokppp ( kde-base/kppp ) So the default is everything, except what the user doesn't want. Implementation is obviously more complex than this, but you all get the idea. I also feel the monolithic ebuilds should be left as is as a) the whole point of them is to always give everything and b) they are being end-of-lifed anyway and won't feature in kde4
No. The meta ebuilds are a workaround for non-existing set-support. And once Portage has provides set support, they will be converted to sets. No use flags, simple don't use the meta ebuild, when you don't want all packages they imply.
(In reply to comment #4) > No. The meta ebuilds are a workaround for non-existing set-support. And once > Portage has provides set support, they will be converted to sets. No use flags, > simple don't use the meta ebuild, when you don't want all packages they imply. Any idea when this mythical set support will appear? I did a fairly long google search for it (never heard of the thing till now) and though I still have no idea what it is, I find this post http://forums.gentoo.org/viewtopic-t-443469.html which is 15 months old. Experience shows that something still unimplemented after that much time is likely to never be implemented at all. Meanwhile, do we expect users to read the kde*meta ebuilds to find out what to merge and what to not merge when installing kde or parts of it? The -meta ebuilds are a vast improvement over monolithic, but they are still clunky to use - I can always get what I want, but it takes way too much digging around compared to selecting features sets in other packages
(In reply to comment #4) > No. The meta ebuilds are a workaround for non-existing set-support. And once Fine. Until this set-support is available, could we please have a workaround for this non-existing set-support? Ie., please allow the users to easily select what they want. *EASILY* is the main point here. Listing all the packages that are wanted is NOT "easily". > No use flags, > simple don't use the meta ebuild, when you don't want all packages they imply. So you're suggesting, that a user should install manually like ~300 packages, just because he doesn't want one particular package? If so, I don't think that this is userfriendly at all. I also don't think it's "simple" to conjure up a list of that many packages. Sure, it can be done, but that's a lot of typing/copy'n'pasting, which is error prone. But maybe I just don't get it. Suppose you want all of KDE, but not kppp. How would you go about this? What would your solution look like? As stated in bug #182099, my solution would be to enhance the kdenetwork-meta ebuild to support a "ppp" flag and build kdenetwork-meta with USE=ppp, if I need ppp and hence kppp support (although I've got to agree with Alan, that a "no-ppp" flag would be the better way to go). Anyway. I'm curious about how you'd solve the "problem" I mentioned in the previous paragraph. Please do NOT resort to editing an ebuild (as this would mean that users would have to do that as well) and also do not use package.provide. (In reply to comment #5) > > Meanwhile, do we expect users to read the kde*meta ebuilds to find out what to > merge and what to not merge when installing kde or parts of it? The -meta > ebuilds are a vast improvement over monolithic, but they are still clunky to > use - I can always get what I want, but it takes way too much digging around > compared to selecting features sets in other packages > Exactly.
The suggestion *seems* rational, but in practice implies that there should be almost as much flags as packages pulled down from kde-meta. I agree with the original suggestion. Just don't use -meta if you don't want ALL of kde.
(In reply to comment #7) > I agree with the original suggestion. Just don't use -meta if you don't want > ALL of kde. Could you offer a solution for the "problem" I posted in comment #6 (ie. install all of KDE, but not one package (or all but a very few))?
(In reply to comment #8) > Could you offer a solution for the "problem" I posted in comment #6 (ie. > install all of KDE, but not one package (or all but a very few))? The solution is definitely not using bugzilla as a discussion forum, nor filling identical bugs under different summaries. If you dislike -meta, then don't use it (or use package.provided). CLOSED.
(In reply to comment #9) > (In reply to comment #8) > > Could you offer a solution for the "problem" I posted in comment #6 (ie. > > install all of KDE, but not one package (or all but a very few))? > > The solution is definitely not using bugzilla as a discussion forum, Where else to go? But wjile we are still here, could you please offer a solution? Thanks. > nor > filling identical bugs under different summaries. I didn't do that. > If you dislike -meta, then > don't use it (or use package.provided). I don't dislike -meta. I just think, that those packages can be enhanced. Hence I filled an enhancement request. > CLOSED. Reopened. Don't close bugs on me like that.
(In reply to comment #2) > So I uninstalled ppp and kppp. Then I ran "emerge -DuvatN world" (which I do > regularly). This emerge run then reinstalled ppp & kppp to satisfy the > dependencies of kdenetwork-meta and kde-meta. 1. emerge kdenetwork-meta 2. emerge -C kppp 3. emerge --depclean 4. emerge -C kdenetwork-meta 5. emerge app-portage/udept 6. emerge --noreplace $(dep -K1 kdenetwork-meta | grep -v "kde-base/kppp") This works fine, I've tested it. While I understand your problem, you really shouldn't re-open bugs just because you don't like the answers you get. Feel free to come to #gentoo-kde on Freenode to discuss with us or mail us, though.
*** Bug 187492 has been marked as a duplicate of this bug. ***
My suggestion is not to add a USE flag for every single KDE package which I think was exaggerated but for the KDE meta packages in kde-meta. This is already done with kde-base/kdeaccessibility-meta by the USE flag accessibility and with kde-base/kde-i18n by the USE flag nls. In my case I want to install the complete KDE except of kdegames-meta. Of course I could do it by not installing kde-meta and installing every other meta package except of kdegames-meta manually. But it was easier if I just could e.g. add a "-games" or "-kdegames" to my USE flags and then simply run `emerge kde-meta`. Or the other way round I could add a USE flag for every KDE meta package like kdegraphics-meta or kdemultimedia-meta which I want to get installed by kde-meta. I guess this would also help with the dependencies of the kde-meta installation. If I first want to install the complete KDE and later decide to uninstall e.g. kdegames-meta. Then revdep-rebuild would reinstall kdegames-meta because it's a dependency of kde-meta, at least it was reinstalled at the next emerge -uDN world.
*** Bug 229783 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > No. The meta ebuilds are a workaround for non-existing set-support. And once > Portage has provides set support, they will be converted to sets. No use flags, > simple don't use the meta ebuild, when you don't want all packages they imply. > As Portage-2.2 introduced set support and it has now been released onto ~arch, we'll be looking into dropping meta packages and creating sets in the short term.
*** Bug 231931 has been marked as a duplicate of this bug. ***
*** Bug 257790 has been marked as a duplicate of this bug. ***
I suggest that at least kde-base/kde-meta be modified with USE-flags so that the rest of the kde*-meta ebuilds can be optionally disabled. A specific use-case for this is would be to disable kdegames-meta in corporate contexts. I've also used the /etc/portage/profiles/package.provided (man 5 portage) file for this, but the grave problem with this approach is that the syntax of this file requires a version number for all listed packages. So each and every time when upgrading, one has to manually fix the version number again and again. :( (In reply to Carsten Lohrke (RETIRED) from comment #4) > No. The meta ebuilds are a workaround for non-existing set-support. And once > Portage has provides set support, they will be converted to sets. No use > flags, simple don't use the meta ebuild, when you don't want all packages > they imply. Time to convert these meta packages into sets for portage-2.2? I just filed bug 496844 so that users could have more control about what will be installed by sets.
