1 |
On Sun, Dec 04, 2011 at 11:10:17PM +0100, Fabio Erculiani wrote: |
2 |
> On Sun, Dec 4, 2011 at 9:35 PM, Sven Vermeulen <swift@g.o> wrote: |
3 |
> > [...] |
4 |
> > The dependency must be on both levels, because the SELinux module must be |
5 |
> > installed before the package is installed (and in theory, RDEPEND could |
6 |
> > trigger an installation afterwards): during the installation phase, Portage |
7 |
> > labels the files on the system (which would get wrong labels if the module |
8 |
> > isn't installed yet[1]). Also, DEPEND isn't sufficient due to binary package |
9 |
> > support requirements. |
10 |
> > |
11 |
> > |
12 |
> > Wkr, |
13 |
> > ?? ?? ?? ??Sven Vermeulen |
14 |
> > |
15 |
> > [1] I am aware that Portage currently installs RDEPEND before the package |
16 |
> > ?? ??itself, but that might change in the future and other package managers might |
17 |
> > ?? ??exhibit different behavior. |
18 |
> > |
19 |
> |
20 |
> I haven't really understood what you mean with RDEPENDs being scheduled "after". |
21 |
> RDEPEND must be always scheduled before the pkg requiring it, |
22 |
|
23 |
While it appears that way, it's not actually true; RDEPEND is what the |
24 |
pkg requires to be able to be usable, not what is required to merge |
25 |
it. |
26 |
|
27 |
Key thing there is the 'run' part; the manager can merge a pkg that |
28 |
isn't yet usable (unsatisfied rdeps), as long as nothing in the graph |
29 |
currently requires the pkg to be working at that state in the build |
30 |
plan. |
31 |
|
32 |
Assuming pkg x DEPENDs on a, and RDEPENDS on b for the context of this |
33 |
discussion, it's perfectly valid for the manager to sequentially build |
34 |
and merge (a, x, b). At the point 'b' is merged, 'x' is considered |
35 |
satisfied/usable. |
36 |
|
37 |
This is the long term rules; the reason it's not obvious is because |
38 |
it's rare for the graph to be flexed in such a fashion that a,x,b is |
39 |
forced rather than a,b,x. Cycles, blockers, odd deps, etc, can |
40 |
force it however. |
41 |
|
42 |
|
43 |
> If you need to schedule a dep install at some point, you should rather |
44 |
> use PDEPEND, but if the same is required earlier in the schedule, |
45 |
> well, you're flooked. |
46 |
|
47 |
In the context of this discussion (apply selinux policies), PDEPEND |
48 |
isn't valid; PDEPEND should be used strictly for for deps that are |
49 |
RDEPEND required, but the pkg can function (degraded) without; this |
50 |
being done for cycle breaking reasons. Well aware people don't always |
51 |
abide by those terms, but that's the actual rules. |
52 |
|
53 |
Selinux wise, the policy needs to be available for applying at merge |
54 |
time, so PDEPEND doesn't fly. |
55 |
~harring |