1 |
On Thu, 30 Jun 2011 20:48:46 +0200 |
2 |
Sebastian Luther <SebastianLuther@×××.de> wrote: |
3 |
> > Portage's behaviour is already broken there -- think what happens |
4 |
> > when ebuilds get removed. |
5 |
> |
6 |
> I know. I'm not opposed to this change, but the needed work flow |
7 |
> change for ebuild devs has to be communicated. |
8 |
|
9 |
Shouldn't be a workflow change. It's already policy to do a revbump if |
10 |
dependencies change. |
11 |
|
12 |
> >> Could you please give a summary (or point me to one) of the |
13 |
> >> discussion about :=/:*? |
14 |
> > |
15 |
> > See the original EAPI 3 discussion. It's all there. |
16 |
> > |
17 |
> Yeah, the whole discussion is there, but not a summary. I don't have |
18 |
> the time to wade through all these mails. |
19 |
|
20 |
Part of the reason EAPI 3 dragged on for so long was that rather than |
21 |
reading the discussion, people would say "I've not read the entire |
22 |
thread, but it seems to me that ...", and then the entire discussion |
23 |
would have to be repeated all over again. |
24 |
|
25 |
If you're just looking for a summary, not details: say a user has |
26 |
cat/dep:1, cat/dep:2 and cat/dep:3 installed, and wants to uninstall |
27 |
cat/dep:1 and cat/dep:2. Say there's cat/pkg installed which has a dep |
28 |
upon cat/dep. Then there's no way for the package mangler to know |
29 |
which cat/dep slots are still 'needed', and which can be safely |
30 |
removed. Thus, to be safe, it has to assume that all three slots might |
31 |
be needed. |
32 |
|
33 |
Nearly all packages that dep upon a slotted dependent have one of two |
34 |
behaviours: they're ok with any slot that matches the rest of the spec |
35 |
(including switching at runtime), or they need the best slot that was |
36 |
present at install time. The former is :*, the latter :=. |
37 |
|
38 |
There are a few perverse cases that don't fit these. Those need special |
39 |
fancy handling, and they're sufficiently fiddly that we shouldn't be |
40 |
holding up solving the large number easy cases to deal with one or two |
41 |
weird packages. |
42 |
|
43 |
> Isn't it desirable that different PMs handle the "no operator" case in |
44 |
> the same way (independently of the question of having one or both |
45 |
> operators available)? |
46 |
|
47 |
The problem is that every way of handling the "no operator" case is |
48 |
wrong for many real situations. You can assume either "any slot" or |
49 |
"best slot", both of which will allow packages to be removed unsafely, |
50 |
or you can assume "all slots", which is excessively paranoid for many |
51 |
packages. |
52 |
|
53 |
-- |
54 |
Ciaran McCreesh |