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.