Dnia 2015-04-04, o godz. 20:14:21 Ulrich Mueller <u...@gentoo.org> 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
pgpk_NuwqEeXq.pgp
Description: OpenPGP digital signature
