2007/9/18, Dan McGee <dpmcgee@gmail.com>:
On 9/18/07, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Idézés Xavier <shiningxc@gmail.com>:
On Tue, Sep 18, 2007 at 02:00:24PM +0200, Nagy Gabor wrote:
> +1 on making -g work both for -S and -R. > > However, why don't we do the following for backwards compatability: > 1. pacman -S grppkg: look for a package named grppkg, then group > 2. pacman -Sg grppkg: look for a group named grppkg (and ignore a > package if there is one) > 3. pacman -R grppkg: only remove a package named grppkg (I don't
> group removal is used enough to warrant keeping backwards compat) > 4. pacman -Rg grppkg: remove a group named grppkg IMHO that would be a bit confusing. And differentiate between group and package install would help to keep the code clean.
Which part exactly is confusing?
I understand Dan's idea, but 1. I don't like "undeterministic" things, so if I (or crond ;-) do a "pacman -Sy favgrp", I want to do a group install independent from the current state of sync repos (today pacman may install a group, tomorrow pacman may install a
On Tue, Sep 18, 2007 at 02:24:24PM +0200, Nagy Gabor wrote: think package...)
2. Why should I do "pacman -S favgrp", when I can do "pacman -Sg favgrp"? 3. Personally, I didn't like the current method either (pacman -S group).
Just so we're clear, it's only the backward compatibility of 1. that you don't like, right? Of course, sorry, if I wasn't clear. +1 for -Sg and -Rg
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'?
Seems OK to me. -- Roman Kyrylych (Роман Кирилич)