From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24877 invoked from network); 3 Dec 2004 09:02:11 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 3 Dec 2004 09:02:11 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1Ca9KM-0004u5-MN for arch-gentoo-portage-dev@lists.gentoo.org; Fri, 03 Dec 2004 09:02:10 +0000 Received: (qmail 17192 invoked by uid 89); 3 Dec 2004 09:02:09 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 11560 invoked from network); 3 Dec 2004 09:02:09 +0000 From: Paul de Vrieze To: gentoo-portage-dev@lists.gentoo.org Date: Fri, 3 Dec 2004 10:01:18 +0100 User-Agent: KMail/1.7.1 References: <20041201175509.GA32317@darkalpt> <200412021349.18285.pauldv@gentoo.org> <1102003872.419.39.camel@exodus> In-Reply-To: <1102003872.419.39.camel@exodus> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1183046.8JZRDW7ou3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412031001.25997.pauldv@gentoo.org> Subject: Re: [gentoo-portage-dev] The merge of emerde with emerge X-Archives-Salt: 873eff9e-3a95-4335-86d8-5030d357b892 X-Archives-Hash: 5a1c39eed4201ce05f6775d0a5f10c03 --nextPart1183046.8JZRDW7ou3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 02 December 2004 17:11, Brian Harring wrote: > Back to the 'make it a wrapper' thing, for it to be external, that's > not in line with the current goals of most of the portage developers- > see genone's omecron design spec, and jstubbs compilation of portage > goals. > Additionally, it will be a pain in the ass forcing the wrapper to > basically duplicate dependency resolution, eg, pulling from it's > tree/repository when possible, falling back to querying portage. > > If it's going to be implemented, it should be implemented _in_ portage > as a specific tree type, with the format properly wrapped/abstracted. > Portage currently isn't incredibly far along in internally wrapping the > ebuild format into it's own class, but it is intended. > ~brian At the point where there are proper modules in portage, I'm all for it to=20 make everything a module. What I mean is that slack code should be=20 modularized in such a way that there is no trace of it when you don't=20 want it. For the current system that means some wrapper of some kind. For=20 a modularized system that means that there is a slack package that=20 installs a number of slackware specific modules and configures portage to=20 use them. Paul =2D-=20 Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net --nextPart1183046.8JZRDW7ou3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBsCtlbKx5DBjWFdsRAlJCAKDo7pFFdLceAQoVHDgZ05Ybb8W09QCfTSap VpBmKNolTMHJmCAjX6VMkng= =cZGU -----END PGP SIGNATURE----- --nextPart1183046.8JZRDW7ou3--