-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone,
Please consider a PROPERTIES=set value that allows an ebuild to indicate that it should behave like a package set when selected on the command line. This is behavior is somewhat difficult to describe in words but the following example should be sufficient to convey the general idea. Consider a case where all of the kde-base/*-meta packages exhibit the "set" property, and these packages and their dependencies are currently installed. In such a case, the default behavior for a command such as `emerge kde-base/kde-meta` should be to reinstall the the selected kde-base/kde-meta ebuild and the set of packages which includes it's direct dependencies and it's recursive "set" dependencies. So, assuming that all USE flags are enabled for the selected kde-base/kde-meta ebuild, it would reinstall the direct dependencies of kdeartwork-meta, kdebase-meta, kdeedu-meta, kdegames-meta, kdegraphics-meta, kdemultimedia-meta, kdenetwork-meta, kdetoys-meta, kdeutils-meta, and kdeaccessibility-meta ebuilds. Similarly, the default behavior for a command such as `emerge --unmerge kde-base/kde-meta` would be to uninstall the same set of packages. The advantage of using the PROPERTIES=set approach, rather than some alternative approach, is that the PROPERTIES=set approach fits nicely into the existing framework, similar to the way that "virtual" ebuilds [1] fit into the existing framework. For example, /etc/portage/package.use can be used to control the USE flags of these "set" ebuilds in the same way that it is currently used to control any other package. Also, tools that are designed to work with existing ebuilds will continue to work just as well with "set" ebuilds. Similar to the proposed "virtual" property [2], the "set" property will indicate that dependency calculations should consider the ebuild to have zero installation cost. Other than this, an ebuild which exhibits the "set" property should behave just like any other ebuild. It should be installed and uninstalled just like any other ebuild, including execution of all the normal ebuild phase functions that would be executed for any other ebuild that does not exhibit the "set" property. Does this seem like a good approach? Are there any suggestions for improvements or alternative approaches? [1] http://www.gentoo.org/proj/en/glep/glep-0037.html [2] http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjezf0ACgkQ/ejvha5XGaN78wCg3RHVdox0VaFq+241zVWRkNTH 6H8AoNNMw/I1bWPzM13yN2PMDg6+MTmD =dxEx -----END PGP SIGNATURE-----
