1 |
Hello, everyone. |
2 |
|
3 |
I'd like to suggest extending the pkgmove (slotmove) action code |
4 |
a little bit to reduce the amount of issues hit by users during |
5 |
the transition period following package moves. Please read on |
6 |
and let me know what you think. |
7 |
|
8 |
|
9 |
The problem |
10 |
----------- |
11 |
|
12 |
Package moves (and slot moves) are currently a three part process: |
13 |
|
14 |
1. committing the package under the new name (slot), and removing |
15 |
the old files, |
16 |
|
17 |
2. updating all package references (*DEPEND, *_version, ...) in other |
18 |
ebuilds, |
19 |
|
20 |
3. adding a pkgmove (slotmove) entry to apply the move on installed |
21 |
packages. |
22 |
|
23 |
This design implies two significant problems: |
24 |
|
25 |
a. with many packages needing changes, the process with CVS is split |
26 |
extends in time and may end up causing users to try to use half-updated |
27 |
package tree, |
28 |
|
29 |
b. third-party repositories need to be updated manually following |
30 |
the changes, and become broken before that is done. |
31 |
|
32 |
While you may say that we can work-around (a) by stopping rsync updates |
33 |
(which we usually don't care to do), and we can ignore (b) many users |
34 |
are actually hitting issues. This has been proved again during |
35 |
the recent eselect move. |
36 |
|
37 |
The common issues include: |
38 |
|
39 |
A. packages still depending on the old package have unsatisfiable |
40 |
dependencies (if the old package was removed before updating the deps |
41 |
-- e.g. third-party repositories), |
42 |
|
43 |
B. file collisions due to PM attempting to install new-named package |
44 |
alongside old one (users syncing before pkgmove is committed). |
45 |
|
46 |
|
47 |
Solution |
48 |
-------- |
49 |
|
50 |
In order to hide those issues from users and provide means for |
51 |
painless migration, I'd like to propose that package (slot) moves are |
52 |
applied not only to installed packages but also transparently to |
53 |
ebuilds during dependency resolution. |
54 |
|
55 |
This specifically means that: |
56 |
|
57 |
1) All dependencies (and has_version, best_version calls) on the old |
58 |
package name (slot) still work, though they get transparently converted |
59 |
to match the new name (slot). |
60 |
|
61 |
2) Developers are expected to commit the pkgmove (slotmove) as soon |
62 |
as the new ebuild is committed, and can remove the old package (slot) |
63 |
afterwards. |
64 |
|
65 |
3) QA tools (repoman) complain about dependencies on old name/slot, |
66 |
either using the regular dependency graph errors (i.e. omitting |
67 |
the update-mapping) or new dedicated checks (additionally listing |
68 |
the new name/slot). |
69 |
|
70 |
Both issues are solved here: |
71 |
|
72 |
A) Users of third-party repositories don't suffer because of package |
73 |
moves -- since the repositories don't have to be updated immediately |
74 |
after the package move. |
75 |
|
76 |
B) Delays in committing package updates to Gentoo don't cause broken |
77 |
dependency graphs -- therefore making it possible to perform updates |
78 |
involving multiple packages in CVS painlessly. |
79 |
|
80 |
|
81 |
Rationale |
82 |
--------- |
83 |
|
84 |
The current package move logic already makes it impossible to use |
85 |
the old name. The Package Managers don't keep track of updates applied, |
86 |
and do re-apply the same update multiple times. |
87 |
|
88 |
Therefore, any reference to the old name (slot) added after the update |
89 |
will still get converted to the new name (slot) next time the updates |
90 |
are applied. In particular, this makes it impossible to add blockers |
91 |
on the old package name. |
92 |
|
93 |
Since the old package name (slot) can no longer be used for any |
94 |
purpose, we can safely map it implicitly to the new package name. |
95 |
No new damage is done. |
96 |
|
97 |
One can doubt that this will result in dependencies not being fixed. |
98 |
However, forcing immediate breakage upon users is not the proper way |
99 |
of enforcing QA. We have repoman and pcheck for that. |
100 |
|
101 |
-- |
102 |
Best regards, |
103 |
Michał Górny |