On Fri, Jan 16, 2009 at 2:58 PM, Nagy Gabor <ng...@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. _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
