1 |
On Sun, 27 Jun 2004 09:47:25 +0900 |
2 |
Jason Stubbs <jstubbs@g.o> wrote: |
3 |
|
4 |
> It would be possible to keep /etc/portage/virtuals. |
5 |
|
6 |
Maybe that's possible, but i don't see how. The system you've |
7 |
proposed is much more powerful than the current one, and that's |
8 |
a problem: a virtual is no more a simple choice between several |
9 |
possible packages, thus user preferences can no more be a simple |
10 |
(set of) package(s) choice. |
11 |
To make use of a simple virtuals file like the one currently |
12 |
available, you would have to limit expressiveness of the |
13 |
dependency formulae you allow in virtual ebuilds. You must allow |
14 |
"|| ( A B C )" but forbid "|| ( A && ( B C ) )". |
15 |
Imo, you can't really use the usual (R)DEPEND but must define a |
16 |
new kind of formula where only depend atoms and arch? or useflag? |
17 |
statements operators are allowed. The list of subformulae would be |
18 |
interpreted as a global disjonction. |
19 |
|
20 |
> Personally, I think it is easier with my proposal. Presently, it |
21 |
> requires scanning for PROVIDE in every ebuild in the tree. With |
22 |
> my proposal, it would only require checking the RDEPEND of the |
23 |
> metaebuild. |
24 |
|
25 |
Here again, the problem is the expressiveness of your model. If |
26 |
you don't require a simple disjonction of dep atoms but allow an |
27 |
arbitrary depencies formula, it becomes hard to calculate its set |
28 |
of models. In general case, the best you can answer is the formula |
29 |
where "arch?" or "useflag?" statements have been interpreted. It |
30 |
means you have to expect answers of the form "A or (B and C)" for |
31 |
instance. That was simply impossible with the original virtuals |
32 |
system, that's why i think it was easier (answers would have |
33 |
always been of form "A or B or C"). |
34 |
But if you take the simplified depend formulae i've described |
35 |
above, then i agree it becomes easy. |
36 |
That say, what is still hard is to know what virtuals a given |
37 |
package instanciates (which is required for instance for a correct |
38 |
implementation of the buildsyspkg feature). |
39 |
|
40 |
> > - it may make packages cleaning a bit harder: [snip] |
41 |
> That is a difficult problem to get around, but exists regardless |
42 |
> of how virtuals are implemented. |
43 |
|
44 |
Exists a bit less with <=.50 implementations: with this versions, |
45 |
it's easy to edit the edb/virtuals file to delete a few obsolete |
46 |
duplicates, and then depclean works fine to finish the cleanup a |
47 |
safe but effective way. |
48 |
I've not experimented much with current .51_pre tho, so i won't |
49 |
comment on this one. |
50 |
|
51 |
> The only way to fix it with my scheme would be to fix depclean |
52 |
|
53 |
Yes. It would need addition of special heuristics for |
54 |
"metaebuilds" dependencies. But for that to work, again, you need |
55 |
to restrict expressiveness of the dep formula. For instance, |
56 |
assuming deps are of the form i've described above, then you can |
57 |
make a depclean that search the smallest solution to this |
58 |
constraints set: |
59 |
- at least one of the possible packages must be kept; |
60 |
- if one is in world, then keep at least this one; |
61 |
- if one is depended directly by another package, then keep at |
62 |
least this one; |
63 |
- if none of the above two cases is verified, then keep at least |
64 |
the first packages from the list of candidates. |
65 |
(or something like that...) |
66 |
My point is that if packagers start to write virtuals with complex |
67 |
dependencies formula (like "|| ( A && ( B C ) )"), then this |
68 |
optimal calculation of what must be kept and what can be cleaned |
69 |
becomes much more tricky. |
70 |
|
71 |
> (which is broken in many other ways as well...) |
72 |
|
73 |
Agreed... |
74 |
|
75 |
> Actually, this problem is worse than you've described. app/fooA |
76 |
> depends on "|| ( bar/pkgA bar/pkgB )" and bar/pkgB is installed |
77 |
> as a dep from app/fooB when app/fooA is emerged. Afterward, |
78 |
> bar/pkgA is installed and app/fooB is uninstalled. depclean |
79 |
> removes bar/pkgB and app/fooA more than likely breaks. |
80 |
|
81 |
Well, yes, that's also bad, but at least this one is right |
82 |
and optimal from the specified dependencies point of view. In |
83 |
the case i've described, that was not even true. |
84 |
The issue in your example is more yet another proof that binaries |
85 |
depencies are more strict than ebuilds dependencies can be. That's |
86 |
close to the openssl 0.9.6 vs 0.9.7 issues (ie. packages can build |
87 |
against one or the other, but once built they can run only with |
88 |
the right one). Or did i misunderstood your example? |
89 |
|
90 |
> Whether it be installed into the var db or not was undecided |
91 |
> and something I hadn't given much thought to. I have no issue |
92 |
> with copying it to the the var db. |
93 |
|
94 |
Imo, it should appear in db, but as a special case (that would |
95 |
hence not be backward compatible): |
96 |
- appear, because it's a necessary link in the backward |
97 |
dependencies calculation. |
98 |
- as a special case, because its presence should not be enough to |
99 |
satisfy a dependency by itself. Think of emerging something that |
100 |
depends on virtual/jre, then decide the default jre (lets say |
101 |
blackdown-jdk) sucks and uninstall it, and then install something |
102 |
else that depends on virtual/jre... result is a non-working |
103 |
package. I know that you can't track deep dependencies every time |
104 |
a package gets installed in current portage. Technicaly, this is |
105 |
just one more case where a broken package is used to satisfy a |
106 |
dependency just because it's there. That's nothing new, but it's |
107 |
much more error prone than with usual packages because user don't |
108 |
really know about this virtuals and hence is not really |
109 |
responsible for the mess he introduces when he uninstall, for |
110 |
instance, blackdown-jdk. |
111 |
|
112 |
So what i suggest is that metaebuilds appear in db, but when they |
113 |
are used in a dep calculation, the algorithm always goes one step |
114 |
further(just like with -u) to check whether at least one concrete |
115 |
packages is really there. And if it's not, then pick the best |
116 |
concrete package taking /etc/portage/virtuals and ordering of the |
117 |
depend formula into account (just like if the virtual wasn't |
118 |
installed). |
119 |
|
120 |
-- |
121 |
TGL. |
122 |
|
123 |
-- |
124 |
gentoo-dev@g.o mailing list |