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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
