From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8044 invoked from network); 16 Jul 2004 10:05:13 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 16 Jul 2004 10:05:13 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BlPaZ-0006IV-TG for arch-gentoo-portage-dev@lists.gentoo.org; Fri, 16 Jul 2004 10:05:12 +0000 Received: (qmail 13467 invoked by uid 89); 16 Jul 2004 10:05:11 +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 13992 invoked from network); 16 Jul 2004 10:05:10 +0000 Message-ID: <38358.202.117.114.8.1089972283.squirrel@202.117.114.8> Date: Fri, 16 Jul 2004 12:04:43 +0200 (CEST) From: "Paul de Vrieze" To: gentoo-portage-dev@lists.gentoo.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [gentoo-portage-dev] Re: Re: portage-ng roadmap? X-Archives-Salt: 3e9224ab-360b-4f4c-902a-b4da0072637f X-Archives-Hash: 6f80e321eb46222532055a21272c3567 >> You're right, they probably don't. My system will be quite modular and I image >> a new tree, maybe I'll implement it in the initial release. One concept I'm thinking about is something I call xpack (where xbuild is the extension of ebuilds that should be guaranteed to work with the new parser). This basically >> is a text based packaging format (like tar, but actually diffeable), that would contain all parts needed for an ebuild (source is optional). Such a file >> would make things a lot easier to manage and to download on demand. > > Totally agree. You can also force a validating commit with cvs : any commit would have to pass QA test (parsing) to be really commited. But, please consider not using rsync anymore. It's too slow for 85 000 files :( > as previously discuss, subversion would be great. The best way is maybe the debian way : Put all xbuilds in a single tar file that would downloaded when "emerge update" (example). Well it should be easy to have a different source of tree information. I like subversion (I maintain the ebuilds), but it does need to stand up to the load that the developers and users put on it. Subversion is also rather hard to mirror so we might want to look to other solutions or have mirrors only mirror the head revision not the below revisions ;-). > >> While my main focus will not be on ondemand downloading of xpacks (ebuilds is >> pointless) it should be fairly trivial to generate metadata files for the packages contained, maybe even on a category level. The transfer size could still be sizeable though. I believe that introduction of xpack files containing everything needed for an ebuild (except the manifest and metadata.xml) allready reduces the amount of files in the tree enormously. It >> also helps in being able to easilly remove unused patches ;-). > > I like this new portage :) > So these xbuilds are not needed on end-users computers. They are only needed to generate the dependance tree. Well think of xpack files as .tar files but text based for nonbinary content. If metadata would be generated from the xbuild files (optional) then that metadata would suffice except for the actual compiling/mergin of packages. > > If you need any help on this, please email me. I'll remember you and surely will ask your help at the point where there's something you can do ;-) Paul -- Paul de Vrieze Researcher Mail: pauldv@cs.kun.nl Homepage: http://www.devrieze.net -- Paul de Vrieze Researcher Mail: pauldv@cs.kun.nl Homepage: http://www.devrieze.net -- gentoo-portage-dev@gentoo.org mailing list