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 1GR7R9-0007io-Sb for garchives@archives.gentoo.org; Sat, 23 Sep 2006 13:20:56 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k8NDJRem032077; Sat, 23 Sep 2006 13:19:27 GMT Received: from rwcrmhc15.comcast.net (rwcrmhc15.comcast.net [216.148.227.155]) by robin.gentoo.org (8.13.8/8.13.6) with ESMTP id k8NDEDG8001568 for ; Sat, 23 Sep 2006 13:14:14 GMT Received: from seldon (c-24-21-135-117.hsd1.or.comcast.net[24.21.135.117]) by comcast.net (rwcrmhc15) with SMTP id <20060923131412m1500las0ee>; Sat, 23 Sep 2006 13:14:12 +0000 Date: Sat, 23 Sep 2006 06:14:12 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC about another *DEPEND variable Message-ID: <20060923131411.GA12282@seldon> References: <45126B07.6030403@gentoo.org> <200609211043.12403.vapier@gentoo.org> <20060921150829.GF30105@seldon> <200609230620.44422.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="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: <200609230620.44422.vapier@gentoo.org> User-Agent: Mutt/1.5.11 X-Archives-Salt: 3bbdd5a4-ff3b-4d55-b75e-7ccb3aaa3546 X-Archives-Hash: c6975679a37648a94ff68dc352237b74 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 23, 2006 at 06:20:44AM -0400, Mike Frysinger wrote: > On Thursday 21 September 2006 11:08, Brian Harring wrote: > > On Thu, Sep 21, 2006 at 10:43:11AM -0400, Mike Frysinger wrote: > > > i'm referring to the specific file of course, not anything else in the > > > package ... so integrating the hack eutils.eclass:preserve_old_lib() = into > > > portage so it isnt a hack (not a knock against the current implementa= tion > > > here; it's always going to be a hack until portage manages proper > > > unmerging of the ABI library) > > > > The reason folks aren't talking about using NEEDED is that NEEDED data > > is generated _after_ building; >=20 > as well it should be ... trying to enumerate the linking ABI possibilitie= s=20 > before hand is not doable and not worth wasting the time of maintainers w= hen=20 > it can be automated >=20 > > getting the info into the resolver=20 > > up front allows for a helluva lot more options, and makes stuff like > > ensuring you have all sources required downloaded *prior* actually > > simple to do, rather then inserting recalculating hacks into the > > resolver. >=20 > rather than integrating it all into the resolver in a one-pass system, a = two=20 > pass system would work: > - build all the packages requested > - after each package, if an ABI library is being removed, check to see i= f it=20 > is needed by any other package. if it is needed, record it and preserve = it=20 > and move on You're assuming that after the merge of the pkg that breaks=20 compatibility, building is actually _still_ possible for the depends. We don't classify our deps as actual build depends vs link depends; as=20 such trying to (essentially) "patch things up after" allow for the=20 scenario where merging breaks the toolchain, thus building isn't=20 possible. Because we don't classify the type of build time dep, that means each=20 DEPEND match must have it's run time depends (RDEPEND) satisfied prior=20 to being usable as a DEPEND; that right there punches a whole in the=20 "delay till the end" approach, and is a good example of what I mean=20 when I say "this is unbounded resolution"; the only way to solve it is=20 to redo the resolution between finished building and merging the pkg=20 to determine if it will break any required DEPENDS for later steps. > - once all the packages requested have been merged, you start the second= =20 > phase and calculate everything that needs to be rebuilt. as ABI libs are= no=20 > longer needed on a system, portage can scrub them out "as ABI libs are no longer needed on a system", phrasing of that=20 implies you're suggesting that portage should leave the older package=20 in place till it's updated all revdeps, then wipe it. Which is fairly nasty, especially if you factor in the user potential=20 of ctrl+c'ing it. Finally, if I'm interpretting your statement there=20 correctly, still isn't guranteed to work- just having the lib around=20 doesn't mean that the older package is left in a working state with=20 the new partially merged over it, only way that would work is if the=20 two were slotted (indicating they could coexist on disk). ~harring --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFFTMjsiLx3HvNzgcRAmviAJ91fLMUo22cxFw9q0tTohhuLX8O7gCfclrN 82FuWWmkmMVqMyax65IlOIU= =OPL8 -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- -- gentoo-dev@gentoo.org mailing list