On 06/01/2012 01:39 PM, Michael scherer wrote:
On Fri, Jun 01, 2012 at 01:18:23PM +0300, Panu Matilainen wrote:
On 05/31/2012 10:24 PM, Adam Williamson wrote:
On Thu, 2012-05-31 at 15:08 -0400, Neal Becker wrote:
But we can, and should, at least try to make our systems tolerant of failures.
Just because we can't test everything. Defensive programming.
Sure. As someone else said, though, that's an issue in rpm if
anywhere...
Dunno what kind of failures you're referring to here (not saying rpm
doesn't have any, just that it's not clear to me in this context),
but
the vast majority of upgrade-related issues are not so much in rpm
but anaconda/preupgrade/yum level of things.
(One of) the recurring themes is
1) user has a system with bunch of non-default packages installed
2) user does an anaconda-upgrade with a DVD
3) anaconda blasts through the upgrade ignoring anything it can't upgrade
4) yum barfs on the resulting broken dependency mess
Anaconda (and perhaps preupgrade as well, I dont know it well enough
to comment) could be stricter and refuse to upgrade unless all
dependencies are met, either through user adding/adjusting (3rd
party) repositories as necessary or removing all offending packages,
but that'd perhaps just create a different kind of PITA.
It would be much better to refuse to upgrade than to break later in weird way,
since users perception would be different.
First, they would either ask for help and then someone could explain what is
wrong.
This would also reduce the number of failed upgrade and therefor the number of
bugs
that cannot be reproduced, thus making them likely easier to spot and fix.
Yup. AFAICS anaconda doesn't even so much as warn about broken
dependencies on upgrade, giving users a false sense of things being all
peaches when in reality it could be creating an enormous mess. Witness
eg https://bugzilla.redhat.com/show_bug.cgi?id=826686 and
https://bugzilla.redhat.com/show_bug.cgi?id=826621 - a user might think
twice before proceeding with an upgrade creating 150-200 broken
dependencies, all of which silently ignored atm.
- Panu -
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
