yum and yum-updatesd in Rawhide
seth vidal
skvidal at fedoraproject.org
Tue Feb 5 23:34:34 UTC 2008
On Tue, 2008-02-05 at 18:10 -0500, James Antill wrote:
> On Tue, 2008-02-05 at 14:33 -0800, Andrew Farris wrote:
>
> > > If I start with no packages and do:
> > >
> > > yum groupinstall Foo
> > > yum groupremove Foo
> > >
> > > ...then I _currently_ end up where I started, so they are _currently_
> > > inverses of each other in that theoretical model ... and the above
> > > change would break that.
> >
> > No it would not. If you have no other groups installed the above change would
> > do exactly what it should and leave you with no packages installed.
>
> What was proposed was:
>
> """
> groupremove by default removes entities that are only found in
> said group and not in other groups or required by things in
> other groups.
> """
>
> So yes, it would, because packages form the groupinstall will be in
> other groups ... so thus. won't be removed by the proposed groupremove.
>
> > On the other hand if you DO have other groups installed that overlap, and then do:
> > > yum groupinstall Foo
> > > yum groupremove Foo
> >
> > You do NOT end up with inverses.
>
> And, again, the proposed change doesn't fix that.
>
> > This is counter-intuitive to someone who asks
> > for something (a group) to be installed and then removed. Despite the fact that
> > they are specifically asking for this behavior it is not what one would expect
> > the behavior to be...
>
> Think of it like this, if I ask for all packages matching "blah*" to be
> installed, and then removed ... those are intuitively "inverses", and in
> theory they are but yum will have a big problem ending up with the exact
> packages you started with for most values of "blah".
>
> > And that stems from the problem that groups overlap in the first place. (also
> > counter-intuitive on the surface level)
>
> Sure.
>
> > > The problem comes when you start with package set X1 (some of which are
> > > in the group you are installing) and groupinstall takes you to the
> > > superset X2, groupremove cannot currently get you back to X1 (even if
> > > you assumed nothing changed in between), without more data and
> > > significantly more work.
> >
> > Ok, I can see where there may be corner cases the straight forward solution I
> > suggested does not work. However, I think it is the best way forward for *some
> > solution* to be developed.
>
> I'm not saying don't come up with other solutions, just that the
> proposed one is worse and more complicated than the current behaviour,
> IMO.
>
> > Any way you want to look at it, a user might actually WANT to remove only the
> > parts of a group that do not overlap.. the stuff he does not want around.. while
> > leaving his other groups intact. At this time the only way to make that happen
> > is to manually list every package he wants removed, and this is definitely
> > sub-optimal.
>
> Sure I can easily imagine lots of use cases, guessing which one applies
> when the user hits return is much less trivial ... see my previous
> example, when "groupremove X" is done, does that mean the user actually
> wanted system-config-printer to go? -- I could make arguments either
> way, and baring something that's right much more often it seems safe to
> go for the easy to explain and current behaviour.
>
So let me add my 2c here.
1. James is 100% correct
2. the groupremove-do-what-I-mean-not-what-I-said mode will NOT be added
to yum.
-sv
More information about the fedora-devel-list
mailing list