When an user types a pre-rename package name (that we know because it's listed in profiles/updates), emerge could explicitly tell user that it's been updated rather than saying that there's no such package and attempting fuzzy matching (which may or may not work). E.g. right now we get: ``` # emerge -v dev-python/discogs-client These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 3.36 s. emerge: there are no ebuilds to satisfy "dev-python/discogs-client". emerge: searching for similar names... emerge: Maybe you meant any of these: dev-python/python3-discogs-client, dev-python/jack-client, dev-python/imapclient? [e] gentoo-amd64 / # emerge -v discogs-client These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 4.10 s. emerge: there are no ebuilds to satisfy "discogs-client". emerge: searching for similar names... emerge: Maybe you meant any of these: dev-python/python3-discogs-client, net-libs/c-client, net-misc/sstp-client? ``` What I'd like to see is: ``` Package "dev-python/discogs-client" has been renamed to "dev-python/python3-discogs-client". ```
We should really do this if we're going to keep renaming things, maybe even automatically use the old name but with a warning (to unbreak scripts).
I've drafted a poor implementation at https://github.com/gentoo/portage/pull/1234 but I'm going to ask Zac for some help on it.
Actually, thinking about it, we should probably go a step further and detect moves for all input atoms even if they do match. This would help if a package is moved in ::gentoo but keeps using old name in an overlay. Otherwise, we'd end up with confusing conflicts.
In other words, if you type app-misc/old, you'd either get: 1. Info that there's no package matching app-misc/old, and it's been moved to app-misc/new, or 2. Info that there's app-misc/old::bar but it's been moved in ::foo to app-misc/new, so the former need to be updated.
(In reply to Michał Górny from comment #3) > Actually, thinking about it, we should probably go a step further and detect > moves for all input atoms even if they do match. This would help if a > package is moved in ::gentoo but keeps using old name in an overlay. > Otherwise, we'd end up with confusing conflicts. If we implement bug 922131, this will be almost unnecessary, right? (apart from edge cases where maybe it's in a profile)
I'm not necessarilty against the idea though, but: a) want to figure out how it differs from bug 922131; b) maybe find some other optimisation first so we're not penalising emerge even more
Bug 922131 is merely about updating *DEPEND in other packages, i.e. the same thing we do to vdb/binary packages. Fixing it would ensure that package moves in ::gentoo won't break their reverse dependencies in overlays. The comment made here is about packages that were moved in ::gentoo but were "forked" in overlays. We can't transparently make them work (because CATEGORY/PN may change), so I think we should warn users that due to pkgmove the "forked" version is no longer usable.
