1 |
Kent Fredric <kentfredric@×××××.com> wrote: |
2 |
> 1. User installs Foo |
3 |
> 2. Gentoo needs to change what Foo depends on |
4 |
> 3. Gentoo simply tweaks the ebuild and doesn't bump [A] |
5 |
> 4. User syncs. |
6 |
> 5. Subsequent emerges see dependencies from [A] which are fixed and works |
7 |
> in the interim |
8 |
> 6. A gets removed. |
9 |
> 7. User syncs. |
10 |
> 8. Shadowing effect of [A] is removed, and Foo is now back |
11 |
> depending on the wrong thing. |
12 |
|
13 |
If you have 6., you have the same szenario even if Gentoo bumps [A], |
14 |
if 4. is omitted (one must not rely on the user syncing very regularly). |
15 |
Even much worse: |
16 |
|
17 |
> I guess, in a way, pkgmove and dynamic deps are the same problem from |
18 |
> different perspectives. |
19 |
|
20 |
s/dynamic deps/changes in dependencies due to tree restructuring/ |
21 |
|
22 |
In a sense, it is. But even if you would use the space-consuming |
23 |
variant of using some history: |
24 |
If the restructuring of the tree happens *after* the package is removed |
25 |
(that is, if 6. happens before the *cause* for 3.) you end up in any |
26 |
case with a situation which can be broken in many aspects. |
27 |
|
28 |
Orphant installs (without a corresponding ebuild) is a situation |
29 |
which is impossible to handle "correctly". |
30 |
The user must *strongly* be adviced ("forced" if gentoo would not |
31 |
always leave choice) to remove the package unless he maintains the |
32 |
corresponding ebuild in his own overlay. |
33 |
|
34 |
Since there is no satisfactory solution for such orphant installs, |
35 |
they should be kept out of the discussion. |
36 |
|
37 |
> pkgmove is an instruction that "set( X ) that requires Y needs to change" |
38 |
> |
39 |
> and dynamic deps are "X requires set ( Y ) and needs to change." |
40 |
|
41 |
s/dynamic deps/changes in dependencies due to tree restructuring/ |
42 |
|
43 |
The difference is that pkgmove can be done generically for all |
44 |
packages while more complicated tree restructuring is impossible |
45 |
to do generically. For instance, for a package split the maintainer |
46 |
of the ebuild has to know which are the correct dependencies; |
47 |
a package merge must usually be combined with appropriate USE-deps, etc. |