> Regardless of implementation, the main goals are: > 1. Adding or modifying advisories is relatively easy. Doesn't require > programming skills. > 2. Adding an advisory in no way risks an ebuild file. An ebuild is > executable code and no one has time to chase down syntax errors. > Advisories are separate. > 3. You don't need to be the package maintainer to do it (though at this > point I'm not sure who would -- maybe a collaboration of forum > moderators and package maintainers?).
Though it's been many moons, and major versions since my last set of major issues with Gentoo upgrades, I would have to agree. I have a set of servers that I am constantly upgrading to minimize the risk of a bunch of breaks in order to only receive a few. For instance, I have overlooked the currently implemented messages in the past due to unattended upgrades. Some of the worse breaks I've had have, on occasion, completely crippled a system. I have started building binary packages as well in an attempt to revert if stuff fails, but sometimes even that doesn't help. Something to this order would be very beneficial. I have currently established a system where I periodically check my scrollback buffer until I find some emerge notes at the end of a package installation. From here I copy and paste the notes into files that I so elloquently name "emerge.<pkgname>.log". This is the easiest way I know to do it. I have looked at the ebuilds before for package information, but this is only helpful if I know that I've missed something, as I don't have time to go over every package that gets installed or upgraded. Usually my process of upgrades consists of simply determining if I need the package or not. I have been trying to find something to this resolve, cause frankly, my system sucks and I know it's probably not the best. For me it's the quickest, and I was not able to think of anything else. This is why I believe you're on the right track. I hope this input helps. Thank you, Robert Larson -- gentoo-portage-dev@gentoo.org mailing list
