1 |
On 2007/10/23, Marius Mauch <genone@g.o> wrote: |
2 |
|
3 |
> On Mon, 22 Oct 2007 21:29:02 -0700 |
4 |
> Zac Medico <zmedico@g.o> wrote: |
5 |
> |
6 |
> > Well, you can already use SLOT atoms in your world file if you don't |
7 |
> > want the highest available. Packages that pull in >=foo are a |
8 |
> > different story though. I suppose we can add something like a |
9 |
> > - --upgrade=minimal option that prevents pulling in new slots if |
10 |
> > they aren't required. |
11 |
> |
12 |
> Don't restrict it to SLOTs though. "minimal" implies that only |
13 |
> upgrades required to satisfy the depgraph are performed. |
14 |
|
15 |
Couldn't this "minimal" behavior just be triggered by lack of the |
16 |
--upgrade option ("emerge -D <set>")? |
17 |
|
18 |
Actually, the current --upgrade behavior (with or without --deep) |
19 |
is a bit weird imho, i would prefer something like this (with foo |
20 |
being either a set or an atom): |
21 |
|
22 |
* "emerge foo": do the minimum upgrades or new installs required to |
23 |
get foo satisfied. Only its direct deps are checked (and direct |
24 |
deps of the unsatisfied ones, etc.), with the "minimal" heuristic |
25 |
(upgrade them only if stricly required). |
26 |
|
27 |
* "emerge -u foo": do all required new installs and possible upgrades |
28 |
of foo. Only its direct deps are checked (and direct deps of the |
29 |
unsatisfied ones, etc.), with the "minimal" heuristic (upgrade them only |
30 |
if strictly needed). |
31 |
|
32 |
* "emerge -D foo": do the minimal upgrades or new installs required to |
33 |
get foo satisfied. Also, check all of its direct and indirect deps, |
34 |
with the "minimal" heuristic (upgrade only if strictly needed). |
35 |
|
36 |
* "emerge -uD foo": do all required new installs and possible upgrades |
37 |
of foo. Also, all its direct and indirect deps are checked, and |
38 |
upgraded where possible. |
39 |
|
40 |
|
41 |
For those who wonder, and if i'm not mistaken, current behaviors of |
42 |
this four combinations, expressed in those words, are: |
43 |
|
44 |
* "emerge foo": do all required new installs and possible upgrades |
45 |
of foo. Only its direct deps are checked (and direct deps of the |
46 |
unsatisfied ones, etc.), with the "minimal" heuristic (upgrade them |
47 |
only if strictly needed). |
48 |
=> same as my "emerge -u foo" |
49 |
|
50 |
* "emerge -u foo": do all required new installs and possible upgrades |
51 |
of foo and its direct deps. Also, check all of their direct and |
52 |
indirect deps, with the "minimal" heuristic (upgrade them only if |
53 |
strictly needed). |
54 |
=> i don't see usefulness of this special case. Whether some code is |
55 |
direct or indirect dep is often subject to some maintainer's choices, |
56 |
and may vary with time (for instance, an internal lib of a big package |
57 |
being splitted out as a separate dep of this package). |
58 |
|
59 |
* "emerge -D foo" and "emerge -uD foo" : do all required new installs |
60 |
and possible upgrades of foo. Also, all its direct and indirect deps |
61 |
are checked, and upgraded where possible. |
62 |
=> same as my "emerge -uD foo". But waste of one of the four options |
63 |
combinations. |
64 |
|
65 |
|
66 |
-- |
67 |
TGL. |
68 |
-- |
69 |
gentoo-portage-dev@g.o mailing list |