On Friday 24 August 2007 14:13:23 Alex Schuster wrote: > So, what I would like is some way of being informed that the next update > of some software would cause major trouble and break many things, leaving > the system possibly unusable for a while, and the choice of not doing so > until I have the time to deal with it. Something like a --force option to > emerge, without which things like expat would not be updated. > > I know, it's not that simple to decide which updates are that critical, > but I think at least in the case of expat we agree that this was a > problem, as e.g. whole KDE was affected. > > A soution might be to slot expat, and issue a > revdep-rebuild --library=/usr/lib/libexpat.so.0.5.0 afterwards. This > makes all the not-yet-broken apps use the new version, which could be > unmerged afterwards. In the meantime, all would be working fine.
Till now I've seen four proposed solutions for this. Two of those are for informing the user before the upgrade and the other two are technical solutions. 1) GLEP 42. Post-sync notification via eselect news. 2) pkg_pretend() in the ebuild which runs at pretend time and is able to notify the user if required. 3) Do proper slotting. 4) preserve_old_lib*() from eutils.eclass. Preserve the .so only and notify the user to run revdep-rebuild --library.. and remove the old lib. I for one am in favour of all of 1), 2) and 3). 1) has been agreed upon but noone skilled enough has found the motivation to make it work with portage. 2) might be agreed upon if the EAPI ever starts moving again.. 3) and 4) are claimed to have unfortunate side effects, but I'm not sure whether that has to be correct (depending on how it's done), and I'm not sure it's any worse than the current situation anyway. -- Bo Andresen
signature.asc
Description: This is a digitally signed message part.
