1 |
Peter Stuge <peter@×××××.se> wrote: |
2 |
> |
3 |
> This suggests another data model bug to me: that dependencies belong |
4 |
> to the dependent packages, rather than to dependency providers. |
5 |
|
6 |
Sometimes it is this way, sometimes the opposite. |
7 |
It would not be natural to associate to a huge library like openssl |
8 |
the packages which use it (or can make use of it if compiled with |
9 |
certain ./configure options). |
10 |
|
11 |
> What I mean is that in the above example, bar "knows" that bar has |
12 |
> turned into bar-{base,gui}, but foo doesn't. |
13 |
|
14 |
But this is not always so. |
15 |
I could also have given the example that bar is replaced by |
16 |
another library which perhaps is (mainly) API but not ABI compatible |
17 |
but nevertheless provides the same command line tools. |
18 |
(Perhaps openssl and some of the planned successors are such an |
19 |
example?) |
20 |
So the installations of bar and bar-successor must block each other, |
21 |
but nevertheless package foo would need to be recompiled if you want |
22 |
to use the modern (presumably "safer") bar-successor - which cannot |
23 |
be done for foo. |
24 |
Again, in this situation the user relies on the outdated bar and |
25 |
does not know it. Or - if something else needs bar-successor - |
26 |
the user gets blockers. |
27 |
|
28 |
> If the user updates their package database things would still work |
29 |
> if 4 modifies the effective dependencies for foo to reflect the new |
30 |
> reality of bar -> bar-{base,gui}. |
31 |
|
32 |
I would be very careful with such magic modifications: |
33 |
It is always dangerous if you rely on a heuristic which needs to |
34 |
be "smarter" than the developer; no matter how many cases you |
35 |
cover in the heuristic, sooner or later there will be some |
36 |
split/replacement/alternative/merge of packages which cannot be treated |
37 |
by the cases covered through the heuristics and which needs |
38 |
some form of manual treatment in some cases. |
39 |
|
40 |
> The more I think about dependencies the more convinced I am that |
41 |
> dependency information must be versioned, ie. dependencies only |
42 |
> matter in the context of the particular package database snapshot |
43 |
> they came from, and that installed dependencies must be kept up to |
44 |
> date as the package database evolves. |
45 |
|
46 |
Yes, this is exactly the problem with static dependencies. |
47 |
Regular revbumps *might* be a solution to this, but there is a |
48 |
certain danger that due to certain (e.g. circular) static dependencies |
49 |
blocking updates on certain user's systems the revbumps remain |
50 |
"invisible" to these users. |
51 |
This is probably not very likely, but I think I could construct |
52 |
realistic such cases (with a "bug" in a dependency, such cases |
53 |
are very easy to construct: Some =... instead of ~... is sufficient). |
54 |
|
55 |
> Otherwise there's just a pile of heuristics, which throw people, |
56 |
> which I guess is why dynamic-deps cause problems and ire. |
57 |
|
58 |
This is exactly the main problem with dynamic dependencies. |
59 |
|
60 |
To summarize a bit differently: |
61 |
|
62 |
The issue is caused by gentoo being a rolling release distribution. |
63 |
This causes permanent tree restructuring, and the latter is |
64 |
incompatible with the idea that a package, once installed, |
65 |
should remain working, unconditionally on the tree changes. |
66 |
|
67 |
Users may expect and wish for the latter, but fact is that these |
68 |
two requirements are in some situations incompatible with each other. |
69 |
|
70 |
If you want a completely safe solution which in no special cases |
71 |
can ever cause any problems, after every sync you would have to |
72 |
unmerge every package and then remerge it again (resolving circular |
73 |
deps by temporary removing of USE-flags and recompiling). |
74 |
|
75 |
The other extreme are dynamic deps without any revbumps ever |
76 |
which take only the rolling release character into account. |
77 |
You have immediately the most current tree information, |
78 |
but in some cases this contradicts the actual installed packages. |
79 |
|
80 |
Now static-deps with many revbump and dynamic-deps with only a |
81 |
revbumps for essential changes are two compromises between these |
82 |
two extremes. |
83 |
Nothing is safe *and* up-to-date in all cases, but both work |
84 |
up to a reasonable number of exceptions: |
85 |
The static-deps are on the "safe" solution side with more recompilations |
86 |
but still possibly outdated information, the dynamic-deps are on the |
87 |
rolling release side, requiring the user to take more responsibility |
88 |
if he wants to avoid a broken system. |
89 |
|
90 |
The highly emotional reactions on the topic are probably due to the |
91 |
fact that corresponding users have systems which for some reason or |
92 |
another should emphasize more the static or "rolling release" type |
93 |
of gentoo: Shifting this emphasis is a politicial issue and |
94 |
fundamental decision, of course. |