From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org)
by nuthatch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-18514-garchives=archives.gentoo.org@gentoo.org>)
id 1GfuN7-0002tw-2U
for garchives@archives.gentoo.org; Fri, 03 Nov 2006 08:25:53 +0000
Received: from robin.gentoo.org (localhost [127.0.0.1])
by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kA38P1NR001300;
Fri, 3 Nov 2006 08:25:01 GMT
Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.200.84])
by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id kA38N3TR011924
for <gentoo-dev@lists.gentoo.org>; Fri, 3 Nov 2006 08:23:04 GMT
Received: from seldon (c-24-21-135-117.hsd1.or.comcast.net[24.21.135.117])
by comcast.net (sccrmhc14) with SMTP
id <2006110308230201400qe627e>; Fri, 3 Nov 2006 08:23:02 +0000
Date: Fri, 3 Nov 2006 00:23:00 -0800
From: Brian Harring <ferringb@gmail.com>
To: gentoo-dev@lists.gentoo.org
Cc: swegener@gentoo.org, dev-portage@gentoo.org
Subject: Re: [gentoo-dev] [RFC] fixing up portage implicit RDEPEND behavior
Message-ID: <20061103082300.GA20674@seldon>
References: <200611030229.46220.vapier@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C"
Content-Disposition: inline
In-Reply-To: <200611030229.46220.vapier@gentoo.org>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Archives-Salt: 11078161-d048-4bf8-87c7-868be995a32a
X-Archives-Hash: 00f926b1fad13be287f275147cbae7db
--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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=20
> your own
That discussion (dropping it to explicit, as has been discussed often=20
enough) should be started off again since fixing it isn't exactly a=20
matter of applying a patch and ignoring it.... so...
swegener? Feel free to chime in, you were one of the main folks=20
after killing implicit from what I recall.
Meanwhile...
> we've said the relationship of DEPEND atoms in ebuilds should be independ=
ent=20
> of the DEPEND atoms found in eclasses as logically ebuilds should not car=
e=20
> what it takes for eclasses to work and vice versa ... for the most part, =
this=20
> is true ...
>=20
> however, semi-recently, a change was made such that the implicit=20
> RDEPEND=3D$DEPEND was dropped from ebuilds if an inherited class set RDEP=
END in=20
> any way ... that means if you have an ebuild at the moment that does:
> DEPEND=3D"foo"
> and you dont inherit any eclasses, then you also get for free:
> RDEPEND=3D"foo"
>=20
> if you decide to inherit eclasses though, you had better do some research=
as=20
> any eclass that does even RDEPEND=3D"" will change that behavior ... or i=
f you=20
> are an eclass writer and you decided to add RDEPEND to your eclass, you h=
ad=20
> better do a reverse check and make sure that any ebuild that inherits you=
r=20
> eclass (directly or indirectly) does not utilize implicit RDEPEND behavio=
r as=20
> you would have just broken it ... awesome ;)
>=20
> i posted a patch to fix this regression, but since it took so long before=
=20
> anyone noticed, zmedico wants to see if anyone is opposed (i dont know wh=
y=20
> they would be, but i cant think of everything)
>=20
> so to recap, the fix here changes it back to the historically documented=
=20
> behavior that the implicit RDEPEND happens in ebuilds regardless of what=
=20
> eclasses do
Mildly screwed on this one from a cache standpoint;=20
1) the change went out unversioned, meaning that while it was=20
spreading, folks were getting a mix of it. Likely their are still=20
cache entries distributed with gentoo-x86 that are still old style=20
deps.
Nice.
2) Same issue via reverting it; it's an unversioned change, so portage=20
will *not* pick up on it and fix it. Additionally, cause I was being=20
anal about making --metadata as fast as possible, portage will *not*=20
pick up the change since mtimes won't differ, thus will not write the=20
new entry into the localized cache (cache.util.py, note the=20
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=20
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=20
the entire tree to be bumped to force falling back to older behaviour=20
(this is why changes like this are supposed to be EAPI bumped in the=20
first place btw).
2) (several steps)
2.a) Revbump all afflicted portage versions with a patch=20
restoring original behaviour, leaving keywords the same (meaning=20
2.1-r3 goes in with stable keywords); pull all portage versions that=20
have the broken behaviour (>=3D2.1 basically).
2.b) Force mtime touches of _all_ eclasses to force both rsync=20
transfer within the mirror tier (can do this other ways), but more=20
importantly, to force the transfer of all eclass consumers to the=20
localized cache on folks machines. This at least gets them the old=20
style deps in their cache. It will *not* fix the rdeps for overlay=20
ebuilds that are afflicted, and does not fix it if the user triggers=20
regeneration locally.
3) ignore it, and laugh like nero till everyone has upgraded to a=20
fixed version of portage and enough churn in the tree has occured to=20
have forced the corrected cache entries locally.
#1 blows since either it requires changing EAPI in every ebuild (=20
easier, base/profile.bashrc, although I never intended profile bashrc=20
to influence ebuild metadata), or auditing the rdeps and fixing them,=20
bumping when after older behaviour. Additionally, requires leaving a=20
portage version behind at the older EAPI for upgrading.
#2 is fairly brutal initially, but should clear out the corruption=20
pretty quickly for majority of users; for overlay users and devs=20
however, it relies on folks upgrading to a fixed portage fairly=20
quickly so that rdeps are proper. Doubly so for devs, since their=20
portage installation is the first line of dependency verification=20
(folks running automated repoman/pcheck dependency scans being second=20
line).
One upshot though, this method will push the proper deps into the=20
localized cache for stage* users.
Downside is that it triggers a pretty heavy hit on rsync mirrors,=20
although the eclass touching can be stretched out over a few days to=20
incrementally push out the updated cache.
#3 means that broken rdeps linger for the next few months till folks=20
have upgraded, and the mess has gradually cleaned itself out. Will=20
linger for a long while in older ebuilds, although a forced cache=20
regen fixes it for folks who either wipe their localized cache, or=20
somehow trigger a regen.
So... I'd go with #2.
Pardon the essay, but getting the effects of it fixed isn't trivial,=20
and the long term lingering effects aren't either imo.
So... thoughts?
~harring
--a8Wt8u1KmwUX3Y2C
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFSvxksiLx3HvNzgcRAu9hAKDMD/58OxOssdKTZ6E2wGPTtcCP+QCgtn/8
nxVXY5YFazAxlP2CkF1bjyU=
=hwjr
-----END PGP SIGNATURE-----
--a8Wt8u1KmwUX3Y2C--
--
gentoo-dev@gentoo.org mailing list