On Fri, Sep 21, 2007 at 06:03:09PM +0800, Xilon wrote:
Another possibility I thought of was simply keeping "pacman -S" for groups, but with the ability to explicitly "pacman -S group/gnome". That way there won't be a problem if a package conflicts with a group. On the other hand this is very odd behaviour, since it is not semantically correct and it appears that the group is a repository.
Indeed, that would be a bit odd :)
I don't think there's really an ideal solution to the problem (if there even is one, as wizzomafizzo pointed out). Adding the -g option might be unnecessary, and installing groups isn't a very regular activity. So far I don't think anyone has complained about the functionality of pacman -S, apart from this one instance where xorg was conflicting. And even so, the xorg group is in testing.
Note that there were two differents proposals : 1) -S and -R look for packages first, and then fallback on groups. -Sg and -Rg only look for groups. 2) -S and -R only look for packages -Sg and -Rg only look for groups. The second idea was mostly defended by Nagy. I think I would also prefer this way, but I think that's the only one that could be problematic for users. What would be the problems choosing the more conservative 1) way? -S and -R will still behave exactly the same in the normal case. In the particular case when there is a package and a group with the same name, use -S / -R for installing / removing the package , and -Sg / -Rg for installing / removing the group. Actually, you were right mentioning the pacman -S <repo>/<package> syntax, it's indeed the same problem. In most cases, it isn't needed. But when there is an ambiguity, pacman offers a way to solve it. But having exactly the same syntax for group and repo is probably not a good idea. Maybe we need to find a similar but different syntax then ? That way, we won't need to add a new Rg option, and to replace the existing Sg by something else (like Slg). But imo, doing this is a not a big problem.