On 2/20/06, Jeremy Katz <katzj@xxxxxxxxxx> 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. 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. -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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
