On Fri, Jan 16, 2009 at 2:58 PM, Nagy Gabor wrote:

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?

I like the idea, and I also would remove the interaction, just displaying a message on upgrade maybe. It could happen in practice that a package is replaced by a set of packages, but I would think that this set of packages could always have one main package depending on the others. So only the main package needs to replace the old one.