From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5838 invoked by uid 1002); 7 Dec 2003 05:05:14 -0600 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@gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 8770 invoked from network); 7 Dec 2003 05:05:14 -0600 From: Paul de Vrieze To: gentoo-portage-dev@gentoo.org Date: Sun, 7 Dec 2003 12:05:09 +0100 User-Agent: KMail/1.5.4 References: <200312050158.17479.george@gentoo.org> <200312061526.52187.pauldv@gentoo.org> <1070739311.6073.365.camel@ht.gentoo.org> In-Reply-To: <1070739311.6073.365.camel@ht.gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_mlw0/LXoP3o7me6"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200312071205.10126.pauldv@gentoo.org> X-Spam-Status: No, hits=-9.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_KMAIL autolearn=ham version=2.55-uvt6 X-Spam-Checker-Version: SpamAssassin 2.55-uvt6 (1.174.2.19-2003-05-19-exp) X-Virus-Scanned: by AMaViS-ng (Milter interface) Subject: Re: [gentoo-portage-dev] portage-ng concurse entry Was: Updated Portage project page X-Archives-Salt: b0baf5fd-efa3-408f-90ab-f94ebb22ddd9 X-Archives-Hash: f44d2950761bcff03f0719e2a52ec9b2 --Boundary-02=_mlw0/LXoP3o7me6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Saturday 06 December 2003 20:35, Daniel Robbins wrote: > On Sat, 2003-12-06 at 07:26, Paul de Vrieze wrote: > > We need indeed a highlevel abstraction, and dep trackers are one of the > > modules. I think that access to the package tree is another, where > > caching can be modular too. > > If by "caching" you mean the metadata cache, this is something I want to > eliminate in portage-ng. I would like things to be designed to be fast > from the start, with no slow bash<->python linkage like there is in the > current portage that makes us require a metadata cache for decent > performance. What I mean with caching here is a module that maskerades as a tree=20 representation, but actually is a cache that gets it's data from another=20 "real" tree representation (be that installed, available ebuilds, or=20 binaries). This cache module would in someway speed up the retrieval of the= =20 data from the cache. Possibly by a binary database or whatever means (I don= 't=20 care). The thing I care about is that it should be optional, and there shou= ld=20 be a caching module that minimizes memory use. > It should be possible to get portage-ng without caching running as fast > as portage does now when it has a fully up-to-date cache. Then if we > need more performance, portage-ng's datastore can be moved to a > database, or we can add an enhanced caching mode to make it even faster. > That would be cool. > For backwards compatibility with existing ebuilds, yes we will probably > still need the metadata cache since we'll still have some kind of bash > linkage. It's important to point out that the design of portage-ng will > not be tied to ebuilds. Ebuilds will likely become "legacy" build > scripts that are superceded by something a lot better, cleaner, powerful > and also faster for portage-ng. While I see the value of keeping ebuilds I agree that ebuilds have serious= =20 upward compatibility problems, so we might get a new format. (Also parseabl= e=20 without bash, and a way to add more complex dependency formats without=20 breaking old scripts). Paul =2D-=20 Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net --Boundary-02=_mlw0/LXoP3o7me6 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/0wlmbKx5DBjWFdsRAlraAJ9iCRexIHrJngZXhX0krG7f1Db9ywCfbojO kwOUVvX06sndgy/NC/CXfiw= =AKIz -----END PGP SIGNATURE----- --Boundary-02=_mlw0/LXoP3o7me6--