Questioning Pirut

[Jeremy Katz]

On Mon, 2006-02-20 at 16:55 -0500, Jeff Spaleta wrote:
> On 2/20/06, Jeremy Katz <katzj at redhat.com> wrote:
> > This is something which I'm a bit open to discussion on -- I think that
> > definitely for the case of updates (pup), the deps are something that
> > you mostly want to accept and not have to actively accept.
> 
> updates involving normal dep resolution maybe... but obsoletes which
> are causing a removal as part of an update? New packages installed
> which are needed by an update of an existing package? or updates due
> to epoch inflation? Do you want that to happen without a review step? 
> I personally consider these package update paths abnormal and consider
> reviewing these actions part of due-diligence.

Which is exactly why you get a dialog to give you the details if you
want, but the vast majority of people aren't going to really want to
deal with them.  For pup, this seems to be working out pretty well

> And beyond pup.. into the realm of pirut functionality where whole
> groups of packages can be removed. You most certaintly want a
> review/accept step. I don't care how well you well think you have
> named a group and how consistently and intuitively you have filled it
> with members, there will be some divergence in the userbase over
> expectations as to what should be removed on group removal. And
> removing groups of packages via pirut without a review/accept stage is
> going to lead to confusion when functionality is removed that users
> didn't expect to be removed via group level removal operations. I
> would say any removal action needs to have a review/accept stage.

Maybe go read the last paragraph of my mail?  Like I said, something
like this for the pirut case could make a reasonable amount of sense.
Going back to a dialog much like the one from system-config-packages
where you get something like (excuse my bad ascii art)
  ----------------------------------
  | Going to install X packages    |
  | Going to remove Y packages     |
  |   v Details                    |
  |                  [Cancel] [OK] |
  ----------------------------------

isn't at all hard to do.  And thinking about things like group removal,
I can see where it makes sense to bring this sort of thing back.  The
question is mostly around whether there's a better way to present the
information

> -jef"can't wait to test how pirut handles group removals when core
> groups are extended by 3rd party repo group definitions which make the
> filesystem member package a member of every defined group.
> Correction...
> I can't wait to users find my 3rd party repo that makes filesystem a
> member of every defined Core group"spaleta

In system-config-packages, we had a nice little check to ensure that you
weren't removing "too many" packages that also checked for some key
packages and gave you a scary looking warning if you did.  

Jeremy