While trying to find out why does emerge still want to install gtk+-1.2, I found strange behaviour. Reproducible: Always Steps to Reproduce: 1. emerge --sync 2. emerge -pt --update --deep world 3. touch /usr/portage/x11-themes/gtk-engines/gtk-engines-2.6.2.ebuild 4. emerge -pt --update --deep world Actual Results: # emerge --update -pt --deep world These are the packages that I would merge, in reverse order: Calculating world dependencies ...done! [nomerge ] x11-themes/gnome-themes-2.10.0 [nomerge ] x11-themes/gtk-engines-2.6.2 [ebuild N ] media-libs/imlib-1.9.14-r3 [ebuild NS ] x11-libs/gtk+-1.2.10-r11 [ebuild NS ] dev-libs/glib-1.2.10-r5 # touch /usr/portage/x11-themes/gtk-engines/gtk-engines-2.6.2.ebuild # emerge --update -pt --deep world These are the packages that I would merge, in reverse order: Calculating world dependencies /QA Notice: has_version() in global scope: eclass gtk-engines2 QA Notice: has_version() in global scope: eclass gtk-engines2 QA Notice: has_version() in global scope: eclass gtk-engines2 QA Notice: sed in global scope: x11-themes/gtk-engines-2.6.2 ...done! # Expected Results: Both updates should give same resuts.
Congratulations, you're about the zillionth person to have been bitten by this. *** This bug has been marked as a duplicate of 24439 ***
Sorry for not spotting that, I tried to find something related to timestamps what failed.
Short version as to why the mtime changed induced different behaviour- portage has a cache of metadata from ebuilds, since this data is seperated from the ebuild, the metadata defined by the ebuild _must_ be constant. The ebuild in question violates this, specifically it is (last I dicked around on that bug) dependant on the local host, which is invalid. Portage detects staleness via mtime of ebuild and eclasses- a touch of the ebuild forced portage to regen the cache for that ebuild, and since it's nonconstant, you suddenly got different deps. (this is why metadata _must_ be constant).
