On 10/04/2010 05:49 AM, Allan McRae wrote:
On 04/10/10 13:46, Allan McRae wrote:
---start paste---
base-devel package not found, searching for group...
:: group base-devel:
One thing I just thought of. If it is going to be separated by repo
could that line say ":: group testing/base-devel" to improve clarity?
Both of the issues you brought up were compromises between simpler code
and friendlier output.
In this case, the fact that the cb_trans_evt callback only accepts two
data arguments is the key.
The two alternatives I looked at it this case (a. is currently in use):
a.
the original pmgrp_t (for the name) and an alpm_list_t (the package list
without cross repo duplicates) are passed to the callback
b.
a temporary pmgrp_t containing the nondupe packages and the pmdb_t are
passed to the callback
Using b., pacman could properly display "repo/group", but both of us
thought that using a temporary pmgrp_t would be a bit unexpected/strange
in the code (even though it yielded the better results).
A "repo/group" display is still possible with a. if we pass a string +
the package list. I don't like this though, other frontends might want
to display this in a different way and having the actual objects to play
with allows for much more flexibility.
I still wonder if it is possible to just have one query for this? I seem
to remember investigating that in the past and deciding it was beyond me
but maybe with the new group code...
I've considered output like this:
xmms-plugins package not found, searching for group...
:: group community/xmms-plugins:
pkg1 pkg2
:: group someotherrepo/xmms-plugins:
pkg3 pkg4
:: Install whole content from community/xmms-plugins? [Y/n]
:: Install whole content from someotherrepo/xmms-plugins? [Y/n]
Alternatively, just ask globally whether to install all:
:: Install whole content? [Y/n]
This is definitely nicer for the end user, but again it would add a bit
more complexity to the code by making us loop through the repos twice.
It can be done though.
