1 |
Michael Orlitzky <mjo <at> gentoo.org> writes: |
2 |
|
3 |
|
4 |
> With dynamic deps, portage will scan (that is, execute) all of the |
5 |
> ebuilds for installed packages that could affect the dependency graph. |
6 |
> If any of those ebuilds have changed, portage will use the new |
7 |
> information rather than the info present when you originally installed |
8 |
> the package. So if the gtk ebuild (that I installed a month ago) has |
9 |
> been altered, portage will re-read it on the fly, ignoring what was in |
10 |
> there a month ago. |
11 |
|
12 |
Seems reasonable from a first glance point of view. |
13 |
|
14 |
|
15 |
> That's nice, because now if you want to install or update something |
16 |
> else, portage doesn't have to re-execute every ebuild/eclass that could |
17 |
> possibly affect the new thing -- it only has to check the VDB. |
18 |
|
19 |
I think that this is what GLEP-64 is all about. Enhancing the functional |
20 |
utilityh of the VDB with a DAG (Directed Acyclic Graph)? |
21 |
|
22 |
|
23 |
> But, if I'm the maintainer of nano and I change that ncurses dependency |
24 |
> (let's say I drop it), then I have to make a revision bump on nano. |
25 |
> Otherwise, the wrong dependency would stay recorded on everyone's |
26 |
> system, and portage would happily use the recorded deps. |
27 |
|
28 |
Basically from my point of view, something like TUP [1] is needed so |
29 |
that at dependency check time you only list files that need |
30 |
attention (linking, loading, compiling etc) thus speeding up the |
31 |
update processes for the Package Manager (portage). I do not study |
32 |
Palaudis or others. |
33 |
|
34 |
|
35 |
|
36 |
> I guess at some point there were a bunch of devs who were messing with |
37 |
> dependencies and not bothering to make revision bumps. This can cause |
38 |
> users pain, so portage added a new option to ignore the cache and rescan |
39 |
> every single relevant ebuild/eclass for sneaky dependency changes. This |
40 |
> ensures that portage has the correct dependencies in its head while it's |
41 |
> doing resolution, but is much slower. |
42 |
|
43 |
There is no proper mechanism to accurately track all of these issue, |
44 |
currently, or did I miss this point? |
45 |
|
46 |
|
47 |
> And then that mode was made default, which is where we are today. It |
48 |
> doesn't sound that bad so far -- just a tradeoff between speed and the |
49 |
> risk of using an incorrect cached dependency. |
50 |
> |
51 |
> Buuuuuuutttttt dynamic-deps mode doesn't always kick in. It interacts |
52 |
> weirdly with subslots and other things. If portage can't find the same |
53 |
> ebuild to scan, it will find one that "looks like it." If that doesn't |
54 |
> work, it's supposed to fall back to the cache. Nobody has a flow chart |
55 |
> of exactly how this works. It's all in the code and there's no |
56 |
> specification. |
57 |
|
58 |
It' a difficult subject so half baked measures abound, imho. A full DAG of |
59 |
the things in the VDB that tracks and retains additional information, is |
60 |
currently one possible solution. But the DAG only collects the data needed |
61 |
to develop more robust tools, or at least that is my understanding. I have |
62 |
read that Ninja, could implement a DAG, but the devs have not made that |
63 |
commitment yet for Ninja. Neil posted a while back about "CheckInstall" |
64 |
which addresses some of the problems that are related too. Thesre are not |
65 |
package managers but merely "tools" that could be employed to resolve some |
66 |
of the related issues. |
67 |
|
68 |
|
69 |
> And, there are other package managers besides portage. When developers |
70 |
> rely on dynamic deps and skip revision bumps, they're screwing users of |
71 |
> paludis and pkgcore (and you, now that you have dynamic deps disabled). |
72 |
> None of the magic is mentioned in the PMS, so you really can't rely on |
73 |
> it and revbumps are needed regardless. |
74 |
|
75 |
The Package Management Specification [3] is also intertwined in this issue. |
76 |
It's a very complicated issue and a problem everywhere you have complex |
77 |
codes and large numbers of codes and packages that define a system. [[4] an |
78 |
excellent read]. Please, folks with deeper understanding, do write as much |
79 |
as you can. An updated gentoo dev blog post, at least framing the issues, |
80 |
would be keen background for everyone, imho. |
81 |
|
82 |
|
83 |
It becomes even more complicated when you look at clusters, the resources |
84 |
and the frameworks to solve problems, including Continuous Integration, |
85 |
compiling across many languages and other goals of the cluster. I am far, |
86 |
far away from possessing a sufficiently deep understanding on these issues. |
87 |
I just peel back a bit of the onion most days and try to discern the issues |
88 |
I encounter:: designing a proper cluster for gentoo does lead one down the |
89 |
path of unravelling these aforementioned issues, and other issues, from the |
90 |
myriad of codes, packages and strategies for distributed computing. |
91 |
|
92 |
|
93 |
hth, |
94 |
James |
95 |
|
96 |
[1] http://gittup.org/tup/ |
97 |
|
98 |
[2] http://asic-linux.com.mx/~izto/checkinstall/ |
99 |
|
100 |
[3] https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification |
101 |
|
102 |
[4] https://blogs.gentoo.org/blueness/2014/08/ |