1 |
What specifically are the phase invariancy and exclusivity requirements |
2 |
for ebuilds? Currently PMS doesn't have anything to say about this; |
3 |
clearly it needs to, since existing ebuilds fairly obviously do have |
4 |
invariancy and exclusivity requirements. |
5 |
|
6 |
Note that we're only discussing package manager related things here. If |
7 |
the user manually upgrades libc / switches compiler / whatever whilst a |
8 |
package manager is busy, there's nothing we can do. |
9 |
|
10 |
Is the following set sufficient? Is the following set the least |
11 |
restrictive correct solution? |
12 |
|
13 |
* No syncing whilst anything else is going on. |
14 |
|
15 |
* Variancy is any package manager action that modifies ROOT in a way |
16 |
that isn't merely a simple addition of something that doesn't alter |
17 |
other packages. This includes any non-default pkg_(pre|post)(inst|rm), |
18 |
merging to ROOT and unmerging from ROOT. |
19 |
|
20 |
* As an exception, changes to DISTDIR do not count as variancy. [1] |
21 |
|
22 |
* pkg_setup does not introduce variancy. [2] |
23 |
|
24 |
* Any pkg_ function that is not the default must be run exclusively. [3] |
25 |
|
26 |
* No variancy may be introduced at any point between a package's |
27 |
pkg_setup run up to the point that it is merged, except for any |
28 |
variancy introduced by that package. |
29 |
|
30 |
* There must be no variancy between a package's pkg_setup and a |
31 |
package's pkg_postinst, except for any variancy introduced by that |
32 |
package. |
33 |
|
34 |
[1]: This allows background fetching. It means DISTDIR can be added to |
35 |
by other processes at any point. It doesn't mean that a package's ${A} |
36 |
can be nuked randomly. |
37 |
|
38 |
[2]: Because otherwise a failed install would result in a damaged |
39 |
system, and an install would temporarily damage a system until |
40 |
complete. Adding a user isn't variancy by our definition, since when |
41 |
combined with the exclusivity requirements it doesn't alter any part of |
42 |
other packages. |
43 |
|
44 |
[3]: Weird stuff happens if, for example, two package's pkg_postinsts |
45 |
are run at the same time, since ebuilds do no ROOT locking. I'm fairly |
46 |
sure the exclusivity needs to be shared amongst all pkg_ phases (think |
47 |
package one doing a useradd fred in pkg_setup and package two doing it |
48 |
in pkg_postinst). |
49 |
|
50 |
-- |
51 |
Ciaran McCreesh |