|
On 06/23/2014 11:51 AM, Gerald B. Cox
wrote:
You present it as simple, but it's really trickier than you imply for several reasons. We discussed several special cases, which you must have missed so let me recall those for your benefit. First, the dependencies. Updates often involve chains of those, and I've seen cases, e.g. caused by a require bugs, where suddenly some system libraries end up scheduled for removal, dragging along tons of dependent packages. Yes, 'yum update' will then ask for confirmation, but it just isn't scalable---the equivalent of 'yum -y update' must be reliable and recoverable even if things go wobbly. Second, kernel updates deleting all old kernels can delete the only running kernel. You can't just say "don't ship broken kernel upgrades" because it's a per-system problem---new ones work for most people but if you are the unlucky person for whom it doesn't work, you are in a bind: - you must upgrade because otherwise you will never get a fix - you can't upgrade because it'll delete the only running kernel, and the new one might not work It just makes a lot of sense to identify and protect a subset of packages whose removal is potentially irreversible. |
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
