[pacman-dev] [PATCH] New Rg option

Dan McGee dpmcgee at gmail.com
Tue Sep 18 09:45:21 EDT 2007


On 9/18/07, Nagy Gabor <ngaba at bibl.u-szeged.hu> wrote:
> Idézés Xavier <shiningxc at gmail.com>:
>
> > 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?
> 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'?

-Dan


More information about the pacman-dev mailing list