| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Hi everyone, |
| 5 |
|
| 6 |
Please consider a PROPERTIES=set value that allows an ebuild to |
| 7 |
indicate that it should behave like a package set when selected on |
| 8 |
the command line. This is behavior is somewhat difficult to describe |
| 9 |
in words but the following example should be sufficient to convey |
| 10 |
the general idea. Consider a case where all of the kde-base/*-meta |
| 11 |
packages exhibit the "set" property, and these packages and their |
| 12 |
dependencies are currently installed. In such a case, the default |
| 13 |
behavior for a command such as `emerge kde-base/kde-meta` should be |
| 14 |
to reinstall the the selected kde-base/kde-meta ebuild and the set |
| 15 |
of packages which includes it's direct dependencies and it's |
| 16 |
recursive "set" dependencies. So, assuming that all USE flags are |
| 17 |
enabled for the selected kde-base/kde-meta ebuild, it would |
| 18 |
reinstall the direct dependencies of kdeartwork-meta, kdebase-meta, |
| 19 |
kdeedu-meta, kdegames-meta, kdegraphics-meta, kdemultimedia-meta, |
| 20 |
kdenetwork-meta, kdetoys-meta, kdeutils-meta, and |
| 21 |
kdeaccessibility-meta ebuilds. Similarly, the default behavior for a |
| 22 |
command such as `emerge --unmerge kde-base/kde-meta` would be to |
| 23 |
uninstall the same set of packages. |
| 24 |
|
| 25 |
The advantage of using the PROPERTIES=set approach, rather than some |
| 26 |
alternative approach, is that the PROPERTIES=set approach fits |
| 27 |
nicely into the existing framework, similar to the way that |
| 28 |
"virtual" ebuilds [1] fit into the existing framework. For example, |
| 29 |
/etc/portage/package.use can be used to control the USE flags of |
| 30 |
these "set" ebuilds in the same way that it is currently used to |
| 31 |
control any other package. Also, tools that are designed to work |
| 32 |
with existing ebuilds will continue to work just as well with "set" |
| 33 |
ebuilds. |
| 34 |
|
| 35 |
Similar to the proposed "virtual" property [2], the "set" property |
| 36 |
will indicate that dependency calculations should consider the |
| 37 |
ebuild to have zero installation cost. Other than this, an ebuild |
| 38 |
which exhibits the "set" property should behave just like any other |
| 39 |
ebuild. It should be installed and uninstalled just like any other |
| 40 |
ebuild, including execution of all the normal ebuild phase functions |
| 41 |
that would be executed for any other ebuild that does not exhibit |
| 42 |
the "set" property. |
| 43 |
|
| 44 |
Does this seem like a good approach? Are there any suggestions for |
| 45 |
improvements or alternative approaches? |
| 46 |
|
| 47 |
[1] http://www.gentoo.org/proj/en/glep/glep-0037.html |
| 48 |
[2] |
| 49 |
http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml |
| 50 |
- -- |
| 51 |
Thanks, |
| 52 |
Zac |
| 53 |
-----BEGIN PGP SIGNATURE----- |
| 54 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 55 |
|
| 56 |
iEYEARECAAYFAkjezf0ACgkQ/ejvha5XGaN78wCg3RHVdox0VaFq+241zVWRkNTH |
| 57 |
6H8AoNNMw/I1bWPzM13yN2PMDg6+MTmD |
| 58 |
=dxEx |
| 59 |
-----END PGP SIGNATURE----- |
Archives