-----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-----