[pacman-dev] Should sync_newversion search for replacements?

Xavier shiningxc at gmail.com
Fri Jan 16 09:57:39 EST 2009

On Fri, Jan 16, 2009 at 2:58 PM, Nagy Gabor <ngaba at bibl.u-szeged.hu> 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.

More information about the pacman-dev mailing list