|Summary:||Request: Option to force rebuild (or unmerge) of all sub-packages associated with a "-meta" package|
|Product:||Portage Development||Reporter:||Epicanis <smc+gbugs>|
|Component:||Enhancement/Feature Requests||Assignee:||Portage team <dev-portage>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Epicanis 2008-07-30 18:01:07 UTC
Not sure how involved this would be but: When rebuilding or unmerging a "-meta" package, emerge should at least have an option to apply the same process to the packages pulled in by the -meta package. (Obvious example: kdebase-meta-9999 from the kde4 overlay. I can install all of the "kdebase" SVN packages - once - with "emerge =kdebase-meta-9999". However, to rebuild, update, or uninstall all of the kdebase SVN packages, I have to track down the individual builds manually and feed their named individually to emerge in some form. (I use this example because unlike the stable kdebase- Would it be possible to get, say, a "--deep-meta" option to apply the emerge command to all packages associated with a -meta ebuild? Reproducible: Always Steps to Reproduce: 1.emerge -v kdewebdev-meta 2.emerge -v --unmerge kdewebdev-meta 3.examine the associated packages (e.g. quanta-3.5.9) - they appear to be left behind. Actual Results: "-meta" associated packages are not rebuilt or unmerged when "-meta" packages are rebuilt or unmerged Expected Results: associated packages should optionally be rebuilt or unmerged Please?...
Comment 1 Zac Medico 2008-07-31 12:16:28 UTC
The closest thing we have now is to use --depclean with no arguments (global depclean). I can add an option that will make --depclean behave how you want when given one or more atoms.
Comment 2 Epicanis 2008-08-02 18:24:37 UTC
Well, that would solve the "--unmerge" issue. How hard would it be to do something similar with rebuilding/re-emerging? (i.e. if "kdebase-meta-3.5.9" and its associated packages are already installed and I want, for example, to rebuild it with different USE flags, I'd like to be able to do something like "emerge --deepmeta =kdebase-meta-3.5.9" and have all the associated packages rebuilt) Perhaps I should also/instead file a request for gentoolkit? Basically what's missing here is a convenient way to get a listing of ebuilds associated with a -meta ebuild. If equery provided an xargs-compatible listing of "reverse dependencies" or something I could get equery to list the packages associated with -meta package and use that listing to unmerge or re-emerge them...
Comment 3 Andrew Gaffney (RETIRED) 2008-08-02 20:00:23 UTC
What's wrong with --emptytree?
Comment 4 Epicanis 2008-08-02 21:55:33 UTC
The problem with --emptytree is that it wants to rebuild far too much - "emerge -v --emptytree =kdebase-meta-4.1.0" wants to re-do 470 different packages on my system, including things like apache, apache-tools, gcc, gentoo-sources, qt, most or all of X.org, etc. etc. In addition to taking WAY too long, it also makes it difficult to (for example) enable the "debug" flag for just this one build on just the kdebase-meta-associated packages without risking unintentionally toggling a "debug" flag on a bunch of unrelated stuff that gets rebuilt with the --emptytree option.
Comment 5 Andrew Gaffney (RETIRED) 2008-08-03 00:55:02 UTC
There really isn't a middle ground with meta packages. However, with sets, this would be far easier to accomplish.
Comment 6 Markos Chandras (RETIRED) 2008-09-21 10:24:51 UTC
This is a very good request. Since portage 2.2 is not stable yet you can use a custom script to do that . Something like for i in $(qlist -C -I kde-base/);do emerge =$i-3.5.10;done Adapt it to your needs Lets hope portage 2.2 will be stable soon :)
Comment 7 Zac Medico 2008-11-13 17:57:13 UTC
One possible solution for this bug would be to implement PROPERTIES=set as discussed here: http://archives.gentoo.org/gentoo-dev/msg_aeb57814a55bb7f8a389a45d87d9449b.xml