[pacman-dev] Sg and Rg options

[Xavier]

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.