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 1FgSxU-0004c4-Li for garchives@archives.gentoo.org; Wed, 17 May 2006 20:49:29 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k4HKm7p2018179; Wed, 17 May 2006 20:48:07 GMT Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.192.81]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4HKhQm8005676 for ; Wed, 17 May 2006 20:43:27 GMT Received: from nightcrawler (c-24-21-135-117.hsd1.or.comcast.net[24.21.135.117]) by comcast.net (rwcrmhc11) with SMTP id <20060517204325m11009ifffe>; Wed, 17 May 2006 20:43:25 +0000 Date: Wed, 17 May 2006 13:43:04 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Paludis and Profiles Message-ID: <20060517204304.GA32706@nightcrawler> References: <20060516161549.442b4d8a@localhost> <20060517000910.5e1f1ccb@sven.genone.homeip.net> <200605170115.33956.kugelfang@gentoo.org> <200605171204.33647.pauldv@gentoo.org> <20060517145705.70b1f15a@snowdrop.home> <20060517181308.GC30935@nightcrawler> <20060517194416.21c39ba5@snowdrop.home> <20060517190609.GF30935@nightcrawler> <20060517205032.36f36418@snowdrop.home> 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="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <20060517205032.36f36418@snowdrop.home> User-Agent: Mutt/1.5.11 X-Archives-Salt: a504ca3c-1785-46b0-992f-7f0089658299 X-Archives-Hash: 2be72e522ec24263574a115ffad3d84e --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 17, 2006 at 08:50:32PM +0100, Ciaran McCreesh wrote: > On Wed, 17 May 2006 12:06:09 -0700 Brian Harring > wrote: > | Clarify on virtuals please. Unless you're mangling the data for=20 > | sym/dir, that's an unmerge time decision (as such it's not vdb data=20 > | specific). >=20 > We're faking new-style virtuals for old-style virtuals, so things end > up in vdb that don't have an associated 'real' ebuild. Portage can't > unmerge them, and it has some trouble with the reduced-content entries > for these too. Instead of on the fly generation of the virtuals pkgs (as=20 pkgcore/portage do), you've flattened them into an actual on disk vdb=20 entry? Re: incompatibility, that can be dealt with by generating a fake=20 ebuild- already generate an env from the looks of it (not seeing=20 anything in RDEPEND/DEPEND however). > | > We went over this already. Remember webapp.eclass? > |=20 > | Nope. Assume I'm stupid, don't ask a question when I ask for an=20 > | answer, just state it please- saves both you and I time. > |=20 > | Do recall they were triggering merge -C calls on their own, but > | that's not portage incompatibility as much as doing something dumb... >=20 > And that's exactly it. At what point does something stop being API and > start being "someone is doing illegal things with internals"? Common sense. Paludis wouldn't like what they were doing any more=20 then pkgcore nor portage- modification of a node cannot cause unstated=20 dependency changes, what they were doing was going outside the=20 constant metadata rules binding all ebuild supporting pkg managers=20 (well, the ones that don't want the 100-400x hit from lacking a=20 metadata cache at least). A real example of where portage doesn't support an ebuild in the=20 tree would be welcome (as stated, if it exists it needs fixing). > | Ebuild is easy- I'm pointing at it because the local env issue should= =20 > | rear it's head there. It's also a tool that ebuild devs rely on=20 > | fairly heavily for debugging, as such two birds one stone (locals=20 > | issue you get to investigate closer, and you flesh paludis out=20 > | further). >=20 > Actually, I was planning to handle that one by BREAK_FUNCTIONS (name > sucks and is not final), which is kinda like SKIP_FUNCTIONS but rather > than skipping, launches an interactive shell. Did something similar with ebuild-shell- folks for the most part liked=20 it. Meanwhile... get cracking, you'll see far more local assumptions=20 transitioning between phases then transitioning between groupped merge=20 phases -> groupped unmerge phases > | > Portage still relies upon being able to source ebuilds, even if > | > their EAPI isn't supported. > |=20 > | Paludis doesn't? >=20 > Nope. Paludis can sanely (as in, treat as EAPI masked) handle ebuilds > that bash can't parse. This paves the way for XML-based ebuilds, which > as we all know is a critical feature required for enterprise support. 'Cept EAPI was specifically targeted at bash based ebuilds only. =20 Alternative formats (non bash fex), expected folks to solve that issue=20 themselves (since I didn't see a sane general solution to it). For what EAPI is defined as, portage supports it fully. > | Related, doc this stuff out please. Portage differences doc you've=20 > | got is more "we're better cause of xyz"- which is fine, but a low=20 > | level "this is what we do differently" (metadata/security fex) would=20 > | at least allow the possibility of folks being on the same page. >=20 > Yeah, that's something that would be useful. I was trying to get spb to > do it... I'd suggest it as priority- it's really not all that fun arguging over=20 details lifted from scanning the code, and getting into terminology=20 wars. Get the doc up, folks can evaluate what the actual support costs for=20 paludis are vs assumptions/guesses. ~harring --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEa4rYvdBxRoA3VU0RAq7rAJ0fhl17Avb47DgrR2KgjswXQo6/8QCgxtjW g2SFmEN0N83St718jWJ+aQ8= =A0fb -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- -- gentoo-dev@gentoo.org mailing list