Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: pms-bugs@g.o
Subject: [gentoo-dev] RFC: extending pkgmove (slotmove) actions to apply transitionally to ebuilds
Date: Sat, 04 Apr 2015 17:10:40
Message-Id: 20150404190422.3b7b3973@pomiot
1 Hello, everyone.
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.
9 The problem
10 -----------
12 Package moves (and slot moves) are currently a three part process:
14 1. committing the package under the new name (slot), and removing
15 the old files,
17 2. updating all package references (*DEPEND, *_version, ...) in other
18 ebuilds,
20 3. adding a pkgmove (slotmove) entry to apply the move on installed
21 packages.
23 This design implies two significant problems:
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,
29 b. third-party repositories need to be updated manually following
30 the changes, and become broken before that is done.
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.
37 The common issues include:
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),
43 B. file collisions due to PM attempting to install new-named package
44 alongside old one (users syncing before pkgmove is committed).
47 Solution
48 --------
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.
55 This specifically means that:
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).
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.
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).
70 Both issues are solved here:
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.
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.
81 Rationale
82 ---------
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.
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.
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.
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.
101 --
102 Best regards,
103 Michał Górny