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