The only reason Mozilla is installed on my machine is because Galeon requires it. But it never fails that everytime Mozilla is upgraded, it takes some time before Galeon is updated to match, and in the interim, it never fails that I wind up with a broken Galeon. Reproducible: Always Steps to Reproduce: Update everything shortly after a new Mozilla has been released. Actual Results: Galeon stops working, and attempting to re-emerge it produces and error because the current stable Galleon ebuild is for a version that doesn't work with the newest Mozilla. Expected Results: Since Mozilla is only on my machine is because Galeon requires it, it should never be upgraded to a version that doesn't work with the current Galeon. Galeon ebuilds should specify a min and max version of Mozilla which they'll work with, and if Mozilla is only on my system because it's a requirement of Galeon, it should never be upgraded outside the range specified by the current Galeon. When a new Galeon is marked stable, and thus my Galeon is upgraded, then and only then should Mozilla be upgraded if there's a newer stable version and it's supported by the newer Galeon.
I already suggested that we should streamline the marking mozilla stable process to fix this problem. it is probably also the way you upgrade that triggers this, if you don't use deep or update for world this shouldn't happen.
*** Bug 40826 has been marked as a duplicate of this bug. ***
I currently have my systems do emerge rsync emerge -u --deep world in a nightly cron job, in order to make sure everything stays up to date. My understanding was that, theoretically, since my CFLAGS are relatively conservative and I don't accept ~x86, this should be safe. From my point of view, if I run those two commands and my system ends up in a broken state, it's a bug. Maybe I misunderstand the safety of those commands?
well, You have found the -reason- that --deep isn't default behaviour anymore. This isn't the only thing it happens with, its just pretty noticeable.
Fair enough. I take it it's not currently possible for an ebuild to specify a maximum version as well as a minimum version of a package it depends on? It seems to me that being able to do so would resolve this problem. Of course, you could then encounter situations where different requested ebuilds could require non-overlapping version ranges of a given package, but at that point, portage could provide a sane error message explaining the conflict. Or are there other problems to this approach that I'm not thinking of? If it's just a matter of it might be a useful thing, but nobody has done it yet/has time to do it, now would probably be as good a time as any for me to get familiar with the internals of portage and contribute something. The problem I see to not using --deep is that if, say, a security problem is found in OpenSSL, it won't get upgraded without me using --deep, or specifically finding out there's a problem and manually upgrading the package. Is there another approach which will avoid leaving problems unfixed in lower level packages, without me taking an active role in learning about them and deciding what to fix? While I'd love to be able to do that, I don't always have the time for it. (As this is becoming more of a philosophical discussion of how things should be done, if it would be better moved to a different venue, like the mailing lists or forums, let me know where I should take it)
The problem is that such a thing cannot be known in beforehand, so it wouldn't help anyhow. I'd suggest the portage development list.
Gents, this discusion about the --deep flag is very interesting, but it doesn't address the fact that even if it WASN'T used in the emerge, mozilla was still upgraded, which broke galeon. The suggested fix for this bug is just to mark galeon 1.3.12 as stable. At the moment it is impossible to build galeon as 1.3.10 checks for the version of mozilla used and it doesn't mozilla 1.6.
This bug is should not be "RESOLVED CANTFIX". Please reopen.
wrong bug, Ooblick. This is for the generic case "updating mozilla". And that is a "CANTFIX".
mozilla should not be updated on itself if it is not in the world file (without using --deep) and that should not happen if you did not update mozilla yourself at some point by hand. But to conlude this, it is in essence a CANTFIX, becuase it's a portage problem really and i personally don't expect this particular area of behaviour to be improved before portage-ng. So the solution really lies in a better streamlining of the stable marking process between the mozilla herd and the herds using the mozilla engine. I CC-ed them here to make them aware of this problem (for as far as they weren't) and discussed some measures with brad to avoid these kind of problems the next time. That is the best we can do at this time.
