On Fri, Nov 03, 2006 at 02:29:45AM -0500, Mike Frysinger wrote: > this is not a "implicit vs explicit" thread; if you want that discussion > start > your own
That discussion (dropping it to explicit, as has been discussed often enough) should be started off again since fixing it isn't exactly a matter of applying a patch and ignoring it.... so... swegener? Feel free to chime in, you were one of the main folks after killing implicit from what I recall. Meanwhile... > we've said the relationship of DEPEND atoms in ebuilds should be independent > of the DEPEND atoms found in eclasses as logically ebuilds should not care > what it takes for eclasses to work and vice versa ... for the most part, this > is true ... > > however, semi-recently, a change was made such that the implicit > RDEPEND=$DEPEND was dropped from ebuilds if an inherited class set RDEPEND in > any way ... that means if you have an ebuild at the moment that does: > DEPEND="foo" > and you dont inherit any eclasses, then you also get for free: > RDEPEND="foo" > > if you decide to inherit eclasses though, you had better do some research as > any eclass that does even RDEPEND="" will change that behavior ... or if you > are an eclass writer and you decided to add RDEPEND to your eclass, you had > better do a reverse check and make sure that any ebuild that inherits your > eclass (directly or indirectly) does not utilize implicit RDEPEND behavior as > you would have just broken it ... awesome ;) > > i posted a patch to fix this regression, but since it took so long before > anyone noticed, zmedico wants to see if anyone is opposed (i dont know why > they would be, but i cant think of everything) > > so to recap, the fix here changes it back to the historically documented > behavior that the implicit RDEPEND happens in ebuilds regardless of what > eclasses do Mildly screwed on this one from a cache standpoint; 1) the change went out unversioned, meaning that while it was spreading, folks were getting a mix of it. Likely their are still cache entries distributed with gentoo-x86 that are still old style deps. Nice. 2) Same issue via reverting it; it's an unversioned change, so portage will *not* pick up on it and fix it. Additionally, cause I was being anal about making --metadata as fast as possible, portage will *not* pick up the change since mtimes won't differ, thus will not write the new entry into the localized cache (cache.util.py, note the is_eclass_data_valid check controlling write_it boolean). #1 was stupid, #2 pretty royally gets us up the backside. So... my suggestion. Decide what you're going to do long term now, no more (bluntly) fucking around with this. Got a few courses of action from where I'm sitting- 1) EAPI bump for the restored behaviour. This sucks since it forces the entire tree to be bumped to force falling back to older behaviour (this is why changes like this are supposed to be EAPI bumped in the first place btw). 2) (several steps) 2.a) Revbump all afflicted portage versions with a patch restoring original behaviour, leaving keywords the same (meaning 2.1-r3 goes in with stable keywords); pull all portage versions that have the broken behaviour (>=2.1 basically). 2.b) Force mtime touches of _all_ eclasses to force both rsync transfer within the mirror tier (can do this other ways), but more importantly, to force the transfer of all eclass consumers to the localized cache on folks machines. This at least gets them the old style deps in their cache. It will *not* fix the rdeps for overlay ebuilds that are afflicted, and does not fix it if the user triggers regeneration locally. 3) ignore it, and laugh like nero till everyone has upgraded to a fixed version of portage and enough churn in the tree has occured to have forced the corrected cache entries locally. #1 blows since either it requires changing EAPI in every ebuild ( easier, base/profile.bashrc, although I never intended profile bashrc to influence ebuild metadata), or auditing the rdeps and fixing them, bumping when after older behaviour. Additionally, requires leaving a portage version behind at the older EAPI for upgrading. #2 is fairly brutal initially, but should clear out the corruption pretty quickly for majority of users; for overlay users and devs however, it relies on folks upgrading to a fixed portage fairly quickly so that rdeps are proper. Doubly so for devs, since their portage installation is the first line of dependency verification (folks running automated repoman/pcheck dependency scans being second line). One upshot though, this method will push the proper deps into the localized cache for stage* users. Downside is that it triggers a pretty heavy hit on rsync mirrors, although the eclass touching can be stretched out over a few days to incrementally push out the updated cache. #3 means that broken rdeps linger for the next few months till folks have upgraded, and the mess has gradually cleaned itself out. Will linger for a long while in older ebuilds, although a forced cache regen fixes it for folks who either wipe their localized cache, or somehow trigger a regen. So... I'd go with #2. Pardon the essay, but getting the effects of it fixed isn't trivial, and the long term lingering effects aren't either imo. So... thoughts? ~harring
pgpFYrGVG1sU6.pgp
Description: PGP signature
