[pacman-dev] [PATCH] New Rg option

Xavier shiningxc at gmail.com
Tue Sep 18 08:32:15 EDT 2007


On Tue, Sep 18, 2007 at 02:24:24PM +0200, Nagy Gabor wrote:
> > 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 think
> > > > 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 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?
1. pacman -S grppkg: look for a package named grppkg, then group

You would rather have :
1. pacman -S grppkg: look for a package named grppkg (and ignore a group if
there is one)

And 2. 3. 4. stay the same.




More information about the pacman-dev mailing list