Here's the scenario. Suppose package A depends on package B. I have both installed. Then I change one of the use flags on B, and execute "emerge --newuse --deep --update world". In some cases, package B is no longer correct, and would have been compiled differently had I chosen the use flags before compiling them. So B should really be re-emerged too, but I don't know that and revdep-rebuild doesn't show it/do it. (For an example of this see bug 79214). Perhaps more generally, anytime a pacakge is compiled in a different way (new version, different use flags, maybe others), everything that depends on it might need to be reinstalled. Best would be if the emerge command could figure out which ones need to be and install them too. If that's too much work, maybe there should be an option to recompile all dependencies on X every time you do emerge X (or emerge world/system and X is one of the packages to emerge). Or maybe revdep-rebuild should do this, but it seems to me more ideal if all this stuff gets taken care of by emerge so the system is never in a problematic state between commands. Reproducible: Sometimes Steps to Reproduce:
If this is a known problem with a package (package B) it should not allow itself to rebuild/upgrade and instead block itself to warn that their will be a problem. mysql for instance can't be upgradeded from <4.1 to >=4.1 due to incompatabilities. emerge -p should beharps list there "problem-packages" aswell that are not going to be upgraded to due blocked depency (from itself)
Hmm, OK. So how then would a package with a problematic USE flag get its USE flag switched, then? By unmerging it first (which would unmerge everything that depends on it), then re-emerging it with the different USE flag? If that's true then "opengl" should become one of these problematic use flags.
It is not per USE flag, but per depenency. Package B has a flag that states that my USE flag "abc" will cause a rebuild of all children. a libc changing it regparams/pic/whatever mode would be a such case.
Maybe I'm not understanding you, but I tried USE="pic" emerge -pv libc and it only listed glibc as packages to be re-emerged.
Yes, but it is not the USE="pic" that makes package A rebuild, but package B tells it (due to its USE="pic"... could also be that package B changes it's binary interface due to version upgrade in general... today we must use revdep-rebuil EVERY time by hand to detect this)
OK, so the deal is that this kind of thing is already supposed to be dealt with by revdep-rebuild, even for USE flag changes, and the case I encountered where it doesn't happen is a specific bug. Is that correct? It would still be nicer if emerge rather than revdep-rebuild dealt with these things, but it sounds like that's already a future goal for Gentoo.
I small tough would be that a package might provide an INTERFACE variable, and when that changes, depended packages must react. The package might deside itself how this variable is constructed. It could construct it like containing concatened strings of use flags that affects the binary-interfaces that are in use and a number at the end that is the binary-interface version. Packages like gtk that upgrades and are backward-compatible would not upgrade it's binary-interface unless it is NOT backward-compatible. a libc wouls construct this variable to be different from the different libc providers, so if you change virtual/libc for the system, all C programs would effectivly be recompiled.
> I small tough Did you make a typo here? I'm not sure what you were saying. No offense.
(minor typos yes "A small idea..." ) Lets say we have package abc. It has severaly USE flags, "foo", "bar" and "debug". All the USE flags can change on this package without problems except "bar" which makes it binary incompatible with other packages that dependens on it. Also, version 1.x and version 2.x of this package are not compatible, and packages depends on this needs to recompile then also. Then this package can have an internal variable that changes depending on bar and version like this +bar, version 1.x gives INTERFACE=+bar-1 -bar, varsion 1.x gives INTERFACE=-bar-1 +bar, version 2.x gives INTERFACE=+bar-2 -bar, varsion 2.x gives INTERFACE=-bar-2 When the INTERFACE variable changes on a package, depended packages of this package must recompile. The variable would be stored along with the other information in /var/db/pkg/ But it is just an idea / Point of view.
Yes, that seems like quite a good idea. But are you saying revdep-rebuild doesn't handle these use flag problems after all?
The problem with revdep-rebuild is that it mostly just check libraries and binary-linking. Epiphany on mozilla is a nice example. If you upgrade mozilla, right-clicking inside the gecko window in epiphany goes a way... Inteprated languages like perl and perl-modules. mldonkey had some compile-problems due to a library it depended on needed to be rebuilt/refreshed.
OK then. So this feature request is still valid. Maybe if Stian's idea is implemented, we won't even need revdep-rebuild anymore. That would mean "emerge depclean" would also have to use the same code to figure out what to re-emerge.
Portage will be getting a new USE-based DEPEND atom type. This will allow a package to depend on another package being built with/without specific USE flags. At the same time that this happens, portage will also start ensuring system-consistency (with regard to dependencies) at all times.
