1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On Saturday 26 June 2004 18:52, Robin H. Johnson wrote: |
5 |
> On Sat, Jun 26, 2004 at 06:27:30PM +0900, Jason Stubbs wrote: |
6 |
> > On Saturday 26 June 2004 17:06, Robin H. Johnson wrote: |
7 |
> > > On Sat, Jun 26, 2004 at 03:06:52PM +0900, Jason Stubbs wrote: |
8 |
> > > > Issue #1: Ignoring dependencies |
9 |
> > > > The "cleaning" of the vardb to trick portage is IMO a bad thing. |
10 |
> > > > There is obviously enough in a stage 1 to be able to build up all of |
11 |
> > > > system, but according to the data portage it is impossible. This then |
12 |
> > > > requires a hack as indicated above to attempt the merge anyway. |
13 |
> > > > However, this hack affects users of installed systems as well as |
14 |
> > > > portage will go ahead and attempt a compilation that is guaranteed to |
15 |
> > > > fail. |
16 |
> > > |
17 |
> > > What's your solution for this? |
18 |
> > |
19 |
> > Well, I don't actually understand why the var db needs to be cleaned. I |
20 |
> > can't see why a combination of --nodeps and --onlydeps on package x and y |
21 |
> > can't solve whatever the problem is, though... |
22 |
> |
23 |
> Try it and see :-), if you don't see why it shouldn't work, it should |
24 |
> probably work... if not fix it ;-). |
25 |
|
26 |
(The following was in regards to this "fix it" - but I just realized that you |
27 |
were probably talking about bootstrap.sh :) |
28 |
|
29 |
I've rewritten the dependency checker as part of the API, but it would be a |
30 |
_real_ pain to port it back to portage. The main issue with the current dep |
31 |
resolver is that if A reqs B and C, and B reqs C, the dep resolution is: |
32 |
* check A |
33 |
* add A to the resolved order, add A to the graph |
34 |
* check B |
35 |
* add B to the resolved order, add B to the graph |
36 |
* add dep from A to B |
37 |
* check C (as dep from B) |
38 |
* add C to the resolved order, add C to the graph |
39 |
* add dep from B to C |
40 |
* check C (as dep from A) |
41 |
* C exists in graph, skip it. |
42 |
|
43 |
The dep from A to C is not included. Emerging goes: |
44 |
* First package added is A.. has deps? yes |
45 |
* Next package added is B.. has deps? yes |
46 |
* Next package added is C.. has deps? no. |
47 |
* Install C and remove its deps. |
48 |
* First package added is A.. has deps? yes |
49 |
* Next package added is B.. has deps? no. |
50 |
* Install B and remove its deps. |
51 |
* First package added is A.. has deps? no. |
52 |
* Install A and remove its deps. |
53 |
|
54 |
Hence, the order is usually right but can go wrong when circular dependencies |
55 |
come into play. |
56 |
|
57 |
> > > I've got no objections to putting the correct information into the |
58 |
> > > tree, but portage needs to be able to handle circular dependancies much |
59 |
> > > better first. One other glaring problem in your listing is |
60 |
> > > sys-devel/make. One other thing that will bite at some points is the |
61 |
> > > things that some upstream developers put into their configure scripts, |
62 |
> > > that are decidedly not always present on a system (perl and rpm to name |
63 |
> > > the worst offenders I've seen). If you can tell me I won't run into any |
64 |
> > > problems by adding in the deps for virtual/libc virtual/cc |
65 |
> > > sys-devel/make etc into my packages, I'll go around and correct them |
66 |
> > > now. |
67 |
> > |
68 |
> > I don't think that the change would bring about any more bad dependency |
69 |
> > ordering than already exists, but I can't be sure. Perhaps, the solution |
70 |
> > is to fix the dependency resolver then fix the packages and then enable |
71 |
> > parallel emerges. That sound acceptable? |
72 |
> |
73 |
> Yup, that should be fine. Before .51 comes out, could you maybe add a |
74 |
> bit of code in repoman to detect circular dependancies (and give a |
75 |
> non-fatal warning at the moment), so we can work on them from an early |
76 |
> stage? |
77 |
|
78 |
I think circular dependencies are inevitable. gcc requires glibc and glibc |
79 |
requires gcc. I don't think there's anything that can be done about that. |
80 |
|
81 |
> I see two cases of circular dependancies that need to be worried about: |
82 |
> - Directly: |
83 |
> pkgA DEPEND on pkgB, and pkgB DEPEND on pkgA - The only solution here |
84 |
> is to code something to work around the circular dependancy, via |
85 |
> bootstrapping one of the packages (similar to getting gcc onto a |
86 |
> machine without a compiler). I know at least one case of this existing |
87 |
> in the tree at a point, but I think it's been fixed at the moment. |
88 |
|
89 |
Presently, I'm using the following logic: |
90 |
1. Install all packages that have no dependencies and remove them from the |
91 |
graph. |
92 |
2. Go back to 1, unless there are no leaf packages. |
93 |
3. Find the smallest circular dependency set. |
94 |
4. Find the total number of reverse dependencies for each package in the set. |
95 |
(A deps on B deps on C deps on D - D has 3 rather than 1) |
96 |
5. Starting with the package with the most reverse deps, iterate through all |
97 |
packages on each of the following steps: |
98 |
a. Install it and go back to 1 if installed packages can satisfy all of its |
99 |
dependencies. |
100 |
6. Ignore dependencies for the package with the most reverse deps. |
101 |
|
102 |
I want to add a 5c for cases where: |
103 |
foo-1 is installed. |
104 |
foo-3 is the latest and requires >=bar-3 |
105 |
bar-3 requires >=foo-2 |
106 |
foo-2 requires >= bar-2 |
107 |
bar-2 requires >= foo-1 |
108 |
|
109 |
> - Conditionally directly: |
110 |
> openldap:DEPEND="sasl? ( cyrus-sasl )" |
111 |
> cyrus-sasl:DEPEND="ldap? ( openldap )" |
112 |
> This one is much simpler, just build one of the two without the USE |
113 |
> flag that causes the circular trap. Then build the other package, and |
114 |
> rebuild the first. Hard part would be choosing which one to build |
115 |
> without the USE flag. A few bugs like this exact one exist, see bug |
116 |
> #33440 to track them. |
117 |
|
118 |
I will be addding a 5b for this. |
119 |
|
120 |
> > > virtual/cc is something I think should exist, as some people want to |
121 |
> > > use dev-lang/icc or dev-lang/ccc instead of sys-devel/gcc. |
122 |
> > > |
123 |
> > > Also, where does the adding of dependancies stop? Eg I have something |
124 |
> > > that uses kernel-headers and glibc, so do I just specify glibc and |
125 |
> > > ignore kernel-headers as that's needed by glibc? |
126 |
> > |
127 |
> > That's a design question that's open to debate. Portage can do it either |
128 |
> > way, but I would suggest that the package depend on both kernel-headers |
129 |
> > and glibc for robustness in the tree. Unlikely in this case, but it |
130 |
> > ensures that a change to glibc's dependencies don't break the packages |
131 |
> > that depend on it. |
132 |
> |
133 |
> Ok, so listing as many dependancies as required (within reason) is |
134 |
> suitable. One other question comes up in your mention of eclasses to |
135 |
> make it easier, namely what's the speed hit going to be with so many |
136 |
> eclasses being added to packages? Won't it be better to change ebuilds |
137 |
> directly? |
138 |
|
139 |
Well, caching should make it fine for end users in terms of eclasses. Brian |
140 |
Harring is currently looking at speeding up portage's bash usage in a way |
141 |
that should more than counter any speed loss, though. More on my mind is the |
142 |
memory and cpu requirements for the shear number of dependencies that there |
143 |
actually are... The dependency graph is much easier and quicker to process if |
144 |
it can be assumed that all packages explicitly state all dependencies, but |
145 |
the actual building of the graph would take more time. |
146 |
|
147 |
Really, I can only offer an opinion on this question. The choice is should |
148 |
really be made by people who have been maintaining ebuilds for a long time. |
149 |
Which way would be easier to maintain? |
150 |
|
151 |
Regards, |
152 |
Jason Stubbs |
153 |
-----BEGIN PGP SIGNATURE----- |
154 |
Version: GnuPG v1.2.4 (GNU/Linux) |
155 |
|
156 |
iQCVAwUBQN1mCFoikN4/5jfsAQLdKQP/fend4MJOZyn57jR/WqgG2wWJ39x/cMpV |
157 |
hjc35ze6oNR2AnKx9L8kGDmDKPudOkVBX6YlOsaL7DFDDtQjXei/RJCfRpA2NiAi |
158 |
TrtJlS4VVg9BAWgOvUw2m9L5bA/k6U9WaZgnrfKbp+yVPS3sbn332GaPVetM7INp |
159 |
CQ9RtvarAtg= |
160 |
=7Ysg |
161 |
-----END PGP SIGNATURE----- |
162 |
|
163 |
-- |
164 |
gentoo-dev@g.o mailing list |