Re: [gentoo-dev] [RFC] fixing up portage implicit RDEPEND behavior

[Brian Harring <ferringb@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5525 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]