On Tue, Sep 18, 2007 at 08:45:21AM -0500, Dan McGee wrote:
I would probably be fine with this behavior, it is just the users you have to contend with. Maybe we could implement it the right way (deterministic behavior) and give a suggestion if no package was found to use '-Sg'?
I brought this topic in #archlinux earlier today, and this wasn't much appreciated indeed. - aep said it would be more confusing - wizzomafizzo was strongly against it : "it is simply extra complication for a problem that's never likely to happen and possible to easily undo if it does" - only Xilon said it would make more sense, but also that it would probably confuse users (but that users should RTFM anyway ;) But wizzo may be right. This situation likely won't happen very often, probably only on metapackage -> group transition. If the group appears before the metapackage is removed from the sync database, then you will just been unable to install the group temporarily, until the metapackage is removed from the sync database. So no big deal. (since you already have the metapackage, you probably don't need to install the group anyway) But after that, you also can't remove the metapackage, which might be a little more problematic. The options that Dan originally suggested would still work though. But in this case, I would prefer them more symetrical, that is : -S and -R look for packages first, and then fallback on groups. -Sg and -Rg only look for groups. Secondly, I began working a bit on this, and I have other questions. 1) -S looks for packages first, then fallbacks on groups. But there is actually a second fallback if group isn't found : providers. But I already saw an user once on IRC who was confused by this behavior : "why the hell isn't pacman installing what I asked it to?" But personally, I think it's a neat feature. eg you can "pacman -S cdrtools" because you only remember that name, and don't know it has been replaced by cdrkit. And pacman will automatically pull cdrkit, since cdrtools doesn't exist but is providen by cdrkit. However, this second fallback stored me a bit when working on the code, so I'm asking just in case :) 2) What should pacman do when one of the targets is not found? Currently, it just fails. This might be the best behavior. But there is also a second option, to try installing / removing what it can find. For example, "pacman -S / -R foo xterm bar" would still install / remove xterm, even though foo and bar don't exist. 3) I was testing a -R option that only removed package, not group. But doing pacman -R xterm with it caused : Erreur: could not remove entry 'xterm' from cache That's because the cache was only loaded by alpm_db_readgrp, which isn't used anymore by this -R option, since it doesn't deal with group. But remove_commit still tries to remove the package from the cache in any cases, with _alpm_db_remove_pkgfromcache. This reminds me of another issue I noticed with the cache a while ago, that I didn't know how to fix either : http://www.archlinux.org/pipermail/pacman-dev/2007-July/008693.html