[pacman-dev] Should sync_newversion search for replacements?

[Nagy Gabor]

This discussion is motivated by FS#11737.

A replacement is nothing more than a simple upgrade with package name
change. (This is plausible, but we don't really follow this principle
atm.) So if we moved our find_replacments code to sync_newversion our
code would be more readable [1]. 

Benefits:
-Qu would also show the should-be-replaced outdated packages.
-During this refactoring we could easily implement FS#11737.
sync_newversion() on foo would do the following: for each database we
try to find a "matching" package (pkgname == foo or bar replaces foo),
and we decide if this is an upgrade or not (if not, return with NULL;
replacement is always an upgrade). This is exactly what we want. (This
demonstrates [1] imho.)

Problems:
-checking replaces is slower, because we must read some desc files, and
sync_newversion() is called in every -S operation (pacman new version
check). If the user's first repo is not core, pacman won't find pacman
literal in this repo and will search for replacements in this repo
before moving to the next repo. This is not a problem with -Su, because
now we always search for replacements first. However, this can be
easily fixed by adding a check_replacements boolean param to
sync_newversion. (However, considering replacements for SyncFirst
packages sounds better theoretically: User can specify any package
there, not only pacman/glibc whose name probably won't change in the
future.)
-user interaction around replacements. Solution1: Basically I don't like
user interaction. Why this PM_TRANS_CONV_REPLACE_PKG is needed at all?
My distro says, that foo is _the_ new version of bar, if I don't want to
upgrade bar, I put bar or foo to ignorepkg. (Of course we should at
least print warning: "foo replaces bar".) Solution2 (uglier):
sync_sysupgrade can compare new and old package name, if they differ
this is a replacement and can get user confirmation. (Or other direct
communication between the 2 functions.)
-however, there is a bigger problem: Multiple package can replace one
package (package split). So if we want to be precise, we should change
the return value of sync_newversion to a package set (alpm_list), not a
simple package, which is totally in needless in most cases. This
annoying fact seems to be a show-stopper... (I don't like ugly code ;-)

So the question is: Should we follow the following rule?:
"At most one package can replace foo per repo."

This is restriction on distro side, and usually I don't like
restrictions. However, I don't know that we have ever replaced one
package by a package set (in Archlinux). And in fact, replacing by a
package set can be confusing to the user:
"Do you want to replace foo with repo1/bar?" Y
"Do you want to replace foo with repo2/baz?" What? I have already
replaced foo. I can choose or it is recommended to use both replacement?
If repo1 != repo2, probably I don't want to install both replacements
(this situation cannot happen in our new approach).
In most cases we can live with one replacement ("core" component or
using dependencies)

If we don't want to follow this rule: Should I drop this whole idea or
use alpm_list_t or do you have any better idea?

Bye