[gentoo-dev] Re: RFC: extending pkgmove (slotmove) actions to apply transitionally to ebuilds

[Ulrich Mueller]

>>>>> On Sat, 4 Apr 2015, Michał Górny wrote:

> The problem
> -----------

> Package moves (and slot moves) are currently a three part process:

> 1. committing the package under the new name (slot), and removing
>    the old files,

Actually, you shouldn't remove the old package at this point because
it would break reverse dependencies.

> 2. updating all package references (*DEPEND, *_version, ...) in other
>    ebuilds,

> 3. adding a pkgmove (slotmove) entry to apply the move on installed
>    packages.

And only at this point the old package can be removed:
https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html#moving-ebuilds

However, all this will be moot once we have moved to git, because
atomic package moves will be possible then.

> [...]

> Rationale
> ---------

> The current package move logic already makes it impossible to use
> the old name. The Package Managers don't keep track of updates
> applied, and do re-apply the same update multiple times.

> Therefore, any reference to the old name (slot) added after the
> update will still get converted to the new name (slot) next time the
> updates are applied. In particular, this makes it impossible to add
> blockers on the old package name.

> Since the old package name (slot) can no longer be used for any
> purpose, we can safely map it implicitly to the new package name.
> No new damage is done.

This is not true for slotmoves. The previous slot can be reused by
versions not matching the dependency spec of the move. One can even
move some versions to a new slot, while leaving others in the old one.

For example, you could have app-misc/foo-1:0 and app-misc/foo-2:0 and
then do the following slotmove:

slotmove =app-misc/foo-2* 0 2

How would your transparent conversion treat >=app-misc/foo-1:0 in a
dependency?

Ulrich