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 ) id 1GR8bV-00035A-Iq for garchives@archives.gentoo.org; Sat, 23 Sep 2006 14:35:41 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k8NEXuXk012094; Sat, 23 Sep 2006 14:33:56 GMT Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.154]) by robin.gentoo.org (8.13.8/8.13.6) with ESMTP id k8NEUMHZ008568 for ; Sat, 23 Sep 2006 14:30:23 GMT Received: from seldon (c-24-21-135-117.hsd1.or.comcast.net[24.21.135.117]) by comcast.net (rwcrmhc14) with SMTP id <20060923143021m14003r15se>; Sat, 23 Sep 2006 14:30:21 +0000 Date: Sat, 23 Sep 2006 07:30:20 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC about another *DEPEND variable Message-ID: <20060923143020.GB12282@seldon> References: <45126B07.6030403@gentoo.org> <200609230620.44422.vapier@gentoo.org> <20060923131411.GA12282@seldon> <200609230950.13347.vapier@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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="i0/AhcQY5QxfSsSZ" Content-Disposition: inline In-Reply-To: <200609230950.13347.vapier@gentoo.org> User-Agent: Mutt/1.5.11 X-Archives-Salt: ab9ebb69-0433-4022-a4a7-3a7d5c0a6aa2 X-Archives-Hash: f39cd199ab49ab937ebf7c7ac28679e5 --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 23, 2006 at 09:50:12AM -0400, Mike Frysinger wrote: > On Saturday 23 September 2006 09:14, Brian Harring wrote: > > You're assuming that after the merge of the pkg that breaks > > compatibility, building is actually _still_ possible for the depends. >=20 > of course i am; i just said that portage would make sure to not unmerge a= ny=20 > ABI lib still in use dlopen? How does this fix openssl horkage? (bad soname handling) Also... what do we do for python/perl (*-updater scripts in general)=20 where a change in a pkg state means we have to rebuild the revdeps? What you're suggesting works for strictly linkage; still think this=20 shouuld work for the general problem rather then just one subset. > > We don't classify our deps as actual build depends vs link depends; as > > such trying to (essentially) "patch things up after" allow for the > > scenario where merging breaks the toolchain, thus building isn't > > possible. >=20 > huh ? RDEPEND is linktime ... see my statement above RDEPEND is execution requirements; to use the binary, this is what=20 needs to be in the graph. Clarifying my statement; we don't break our DEPEND down into "this is=20 what is executed in building the package" (toolchain), vs "this is the=20 crap the binaries we build against need avail to be linked against",=20 literally what winds up as -l args. If punting the old lib (as I assumed), means we would potentially be=20 making certain DEPEND atoms unusable if they're required in an=20 execution context (rather then just winding up as a -l arg). So... ignore that bit since you're talking about lingering files. > > > - once all the packages requested have been merged, you start the se= cond > > > phase and calculate everything that needs to be rebuilt. as ABI libs= are > > > no longer needed on a system, portage can scrub them out > > > > "as ABI libs are no longer needed on a system", phrasing of that > > implies you're suggesting that portage should leave the older package > > in place till it's updated all revdeps, then wipe it. >=20 > no i am not; read my previous e-mails where i said it would leave behind = the 1=20 > ABI lib required ... aka whatever is encoded in SONAME Yeah, missed the "presvered" (woot for 5am wakeup). In that case, wouldn't mind a response to the "what about ctrl+c=20 during the run?" The potential for orphaning there sucks; recording=20 the old library in the new version sucks also since it complicates the=20 merge process, that lib *must* be removed else it's a potential=20 collision-protect minefield. Finally, even if the lib is temporarily left behind, this solution=20 doesn't gurantee the library actually would *work* still- it only can=20 work if the lib is standalone from the rest of the pkg and doesn't=20 rely on any external data from the pkg. Example would be pkg foobar that internally has libconvience, used by=20 it's libs but not externally linked, contains (oddly enough)=20 convience bits shared across foobars libraries. =20 libconvience is *not* to be externally linked against, consumers must=20 access the other libs (say libfoo); any soname bumps to libfoo, the=20 old version gets broke in the process despite due to it linking=20 internally against an unversioned so. Granted, semi retarded, but gnomes libegg comes to mind as a potential=20 case of this. Basically trying to point out that what you're proposing only works in=20 a subset of the cases revdep must deal with, and that revdep itself=20 doesn't deal with *all* situations as is; hence BINCOMPAT as a way to=20 try and shift it under maintainers control. Maintainence of it *should* be pretty simple also; for sane upstream=20 soname handling, you just bump it with the majors; for the rest, its a=20 knob that can be fiddled to at least give up front warning of the=20 issue. ~harring --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFFUT8siLx3HvNzgcRAjecAKDgSdtEGLNr1C4G4NdyDPu59mLCgACfRCNW W1hmaBGK+LPP34ZvxblrSMo= =3SwF -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ-- -- gentoo-dev@gentoo.org mailing list