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

[Michał Górny]

Dnia 2015-04-04, o godz. 20:14:21
Ulrich Mueller <ulm@g.o> napisał(a):

> >>>>> 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.

I wasn't listing the steps in order.

>
> > 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.

No, the issue of third-party repositories will still be valid.

> > [...]
>
> > 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?

As far as I'm concerned, this is a hack and as such it doesn't have to
cover all the possible cases.

-- 
Best regards,
Michał Górny