Libs with big ABI changes : request more verbose emerge

[Naib]

with fallout from the expat major bump all but over (maybe?) could more be done to minimise the damage?
Expat isn't alone in that other programs need to be re-built against it when a big bump comes (dbus went through it a few months back, any time there is a bump of directfb any app with the "directfb" USE flag needs re-doing)

is it possible that a hack be done to emerge such it pauses the ebuild (a bit like the -a emerge flag) and prints some message giving some prior warning.
eg maybe some extra variable added to the relevant ebuilds (upon next bump which requires a revdep-rebuild to be run) such that emerge acts upon that. That way those willing to try it can but those not wish a potential breakage can hold off until any potential bugs & suitable upgrade commands can be figured out

Such and update problem is going to occur again
_________________

[AllenJB]

I'd also like to see this, but to maintain the "non-interactivity" of emerge, I believe the user should be notified before any actual emerge begins, at the same point -p / -a / blocks occur.

[Naib]

yer thats what I ment, not it carries on through UNTIL it hits the ebuild which could cause an issue BUT it does it right at the start, giving the user the option to not start the emerge and mask the package, or accept and continue

maybe add another FEATURES option to make.conf for those that want to just accept these by default (dev's, users that don't mind the fun)
_________________

[steveL]

We're working on this for update: we have a WARN mechanism (unreleased) but I'm thinking now we should just scan for revdep-rebuild in the same way we do for config updates.

Adding a flag to the ebuild sounds like a good option to me. The WARN mechanism would be more flexible; in server (non-interactive) mode the package is masked temporarily, and a warning message is displayed and logged, so the admin should be aware there is a large revdep. In interactive mode the user is asked what to do; if no fix is available default is to mask package or user can just say to skip it (which might mean other packages will fail dependency check- this is slower in the long run, since every package in the list after expat would have a pretend emerge run to make sure portage didn't think it needed expat-2.) If there is a fix, the default is again to mask, so the user has to specifically ask to run the large revdep.

The fix can include packages to build before or after as well as libraries to check with revdep-rebuild, and also says which version the user needs to be upgrading to (in this case expat-2*) and from (<2) so the check can be skipped eg if upgrading to expat-2.1 from expat-2.0. Before there is a fix, there is just a pkg eg dev-libs/expat-2 which works as a temp mask by default. Thing is, this would need eg /usr/portage/warnings or similar which would be updated by devs as soon as they found a problem like this, and thus rsync'ed to users, to be really effective, and I don't know if any devs would want to do that. OFC we could do it as users (ie as soon as there's an issue noticed on IRC or the forums) but it wouldn't be so useful.

So on balance, I think we'll add the revdep-rebuild scan, and the warn file can be there as a back-up if anyone wants to add to it. For instance, I understand dbus hal pango cairo gtk and curl should be rebuilt after expat, if the user has them. (A definitive list would be nice for new installs; I'm sure someone mentioned some XML stuff.) If we can do the most common packages straight away, it'll make revdep's job a lot easier. (I understand dbus and hal were the reason so many KDE packages came up in revdep.)
_________________

[Genone]

portage-2.2 already has a new FEATURE "preserve-libs" that will keep the old library around until all packages linked against it have been rebuild.