yum plugin suggestion or yum change?

Jeff Spaleta jspaleta at gmail.com
Mon Dec 5 16:17:46 UTC 2005


On 12/5/05, Jack Tanner <ihok at hotmail.com> wrote:
> Think "Aunt Tillie". She's got one PC, not several. She just wants it to
> be safe from the baddies on the intraweb. QA of an update at a time,
> with individual QA of each dependency, is not something she is going to
> do. The simple desktop use case is to turn on automated nightly updates,
> and to let power users and sysadmins turn those off at their own risk.
> "Partial" automated updates do make sense for this scenario.

What AT wants and what is a best practise for AT's situation are very
different things.
I understand that people "desire" the ability to have reliable
automated updates that require absolutely no interaction with the
system. I don't think this project can provide that facility
"reliably" for the majority of users.  And if it automated updates
can't be done reliably, then this project should instead focus on
notification of updates and user initiated update pulls.

I am not convinced that partial updates are in AT's best
interest...even though its desired.
Allowing normal people to easily ignore errors will only serve to
reduce the amount of error reporting that is occuring about package
updates.  Letting users ignore errors by default even more so.   If
partial updates can be accomplished with a click of a button, whatever
dialog the AT oriented tool throws up about errors becomes nothing
more than a nag dialog to click through. Turning update error dialogs
into EULA-like nag windows that AT isn't going to read is not useful
nor is it wise. If something unexpected happens AT needs to be told,
and needs to be told how to contact people who can help her
understand, report and resolve the problem.  What if the update that
isn't being installed IS a security fix?  Since the tools have no
ability to distinguish security updates from feature updates, how can
it be safe to encourage AT ignore the problems?

-jef




More information about the fedora-devel-list mailing list