[pacman-dev] [PATCH] Add more information in conflicts question

Rémy Oudompheng remyoudompheng at gmail.com
Sun Apr 17 05:50:31 EDT 2011


On Sun 17 April 2011 at 17:03 +0800, Sebastian Nowicki wrote:
> In addition to the names of the conflicting packages, the origin and
> versions will be displayed to the user.
> 
> This introduces a slight API change in the PM_TRANS_CONV_CONFLICT_PKG
> conversation callback. The format of the first two strings has changed
> from package names to strings of the format "db/name-version".
> 
> Fixes FS#12536
> ---
> 
> I rewrote the patch to pre-format the package information rather than
> changing the API completely, as per Dan's suggestion. This still
> introduces a bit of an API change as the two string can no longer be
> used as package identifiers, e.g. in alpm_db_get_pkg().
> 
> $ sudo ./src/pacman/pacman -S qemu-kvm
> resolving dependencies...
> looking for inter-conflicts...
> :: extra/qemu-kvm-0.14.0-1 and local/qemu-0.14.0-1 are in conflict (qemu). Remove local/qemu-0.14.0-1? [y/N] n
> error: unresolvable package conflicts detected
> error: failed to prepare transaction (conflicting dependencies)
> :: qemu-kvm and qemu are in conflict
> 
>  lib/libalpm/sync.c |   51 ++++++++++++++++++++++++++++++++++++++++++++++++---
>  1 files changed, 48 insertions(+), 3 deletions(-)

I am totally against this. Really really totally.

I personally think a formatting function for package information has
strictly nothing to do in sync.c, and maybe not even in libalpm.
Second, it would introduce additional parsing effort from front-ends to
split against the passed string if they want to display information in a
different way.

And what output do you expect if a conflict arises when running
pacman -U ?? What do you think is the repository from a package loaded
from a file.

I don't even understand why we would want to display any sort of version
information. I don't see how it would help me answer yes or no to that
conflict question either.

That is in my mind the job of the front-end: if you really
want information, it should display the list of selected packages
(repository/pkgname-pkgver) that comes between the parsing of the
command-line and the beginning of the transaction.

For example:

cb_trans_conv (from pacman) should be patched to display :
  :: target qemu-kvm conflicts with installed qemu. Remove qemu ?

which is perfectly clear: qemu is installed and pacman wants you to
remove it, "local/qemu" brings no additional information, and the version
number is usually meaningless. The callback returns precisely one local
package and one target package, it can be reflected in the user output.

If you need to display the version number, then I don't feel like
messing with libalpm's internals is the right answer. I would probably
prefer have process_targname() patched (in pacman/sync.c), so that
after running alpm_find_dbs_satisfier(), it prints something.

If I run "pacman -S x-server", I want to see :
 "selecting extra/xorg-server providing x-server"
(the case where alpm_find_dbs_satisfier() returns a package whose
name differs from the requested name => any further references
to xorg-server refer to extra/xorg-server and it's totally clear)

If I run "pacman -S kernel26", I'd like to see :
 "selecting testing/kernel26-2.6.39-1 (over extra/kernel26-2.6.38.2-1)"
(the case where the pkgname exists in multiple DBs)

I think it should remove most ambiguities with least intrusive changes.

However, I think modifying the callback to return pmpkg_t is not a bad
idea, but then the formatting function should go in pacman. I just want
to understand the first reason why we are doing this. The bug report is
totally inconsistent (the title is inconsistent with the described
problem and so on), and it seems we are trying to solve some imaginary
problem.

The best thing we can probably do is make libalpm functions return more
information about their internal processing. Modifying formatting will
not help that. And if people want to know why some package suddenly
appears in the target list, I fear there is no solution.

-- 
Rémy.


More information about the pacman-dev mailing list