Gentoo Archives: gentoo-dev

From: Martin Vaeth <martin@×××××.de>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: don't rely on dynamic deps
Date: Tue, 29 Jul 2014 10:21:41
Message-Id: slrnltetc8.6ov.martin@epidot.math.uni-rostock.de
In Reply to: Re: [gentoo-dev] Re: don't rely on dynamic deps by Peter Stuge
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.