If an ebuild exists in both the main portage tree and the overlay, portage uses the one modified most recently. Therefore, an emerge sync will effectively cause portage to use the ebuilds in the main tree in favor of the ebuilds in the overlay. Expected behavior: Portage should use ebuilds in the overlay regardless of the date modified.
*** Bug 16778 has been marked as a duplicate of this bug. ***
That's not true. Timestamps are maintained in the portage tree. If an ebuild is updated it's probably to your benefit to use that update. If you want to use a particular ebuild always, then use a revision that is quite high. -r99 would work.
>> That's not true. Timestamps are maintained in the portage tree. What do you mean? If it's not true, then what causes this? # emerge -p -u world These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild UD] media-libs/freetype-2.1.2-r2 [2.1.3-r2] [ebuild UD] media-libs/fontconfig-2.1 [2.1-r1] [ebuild UD] x11-base/xfree-4.2.1-r2 [4.2.99.4] [ebuild U ] media-libs/xine-lib-1_beta2 [0.9.13-r2] [ebuild UD] net-www/mozilla-1.2.1-r5 [1.3_beta] # find /usr/local/portage/ -type f -exec touch {} \; # emerge -p -u world These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild U ] media-libs/xine-lib-1_beta2 [0.9.13-r2] >> If an ebuild is updated it's probably to your benefit to use that update. Agreed. But none of the above were updated, they were just re-sync'ed. If there is an ebuild with the same version and revision number both in the main tree and in the overlay tree, portage should pick the one in the overlay, as it has before. If it is there, it's because the user put it there, and he did it because he wants to use that one instead of the official one. That's pretty logical to me. >> If you want to use a particular ebuild always, then use a revision that is quite high. -r99 would work. Yes, that would work, but I don't want to use particular ebuild always. I want to use that particular locally modified revision _only_ until there's a newer revision. Renaming it to -r99 would prevent any true updates. Besides, this would be a workaround to a portage bug, not a solution to that bug. "Blame the user instead of the application" is not a good policy. This bug should be reopened, since it's not fixed and is by no means invalid.
Apparently I came to an incorrect conclusion about the cause of the bug. I mistakenly assumed that 'emerge sync' touched the entire portage tree. The bug still exists, however. I often copy ebuilds to my overlay in order to change the KEYWORDS from "~x86" to "x86". I'm not avoiding updates; I'm simply unmasking ebuilds I want to test. Previous to 2.0.47, this worked flawlessly. Now, as Felipe and Christian (from the duplicate bug #16778) describe, 'emerge sync' makes portage forget about the unmasking in my overlay until I touch the entire overlay tree.
This is fixed in 2.0.48. Thanks.
