From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14549 invoked by uid 1002); 29 Nov 2003 00:51:10 -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@gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 758 invoked from network); 29 Nov 2003 00:51:10 -0000 Message-ID: <3FC7EC84.90806@technaut.darktalker.net> Date: Fri, 28 Nov 2003 18:47:00 -0600 From: Andrew Gaffney User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031117 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-portage-dev@gentoo.org References: <1070045720.12096.43.camel@ht.gentoo.org> <200311282315.57449.pauldv@gentoo.org> In-Reply-To: <200311282315.57449.pauldv@gentoo.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-portage-dev] portage-ng requirements doc X-Archives-Salt: 98ee7aff-972b-4a29-a69d-5b02ff3d4625 X-Archives-Hash: 33dc8aedcd897f4436b85074011e4ded Paul de Vrieze wrote: > Below I'll give my shot at it. > > On Friday 28 November 2003 19:55, Daniel Robbins wrote: > >>architecture requirements: >> >>1) facilitate parallel, community development >>2) allow for easy extensibility and new feature additions over time >>3) provide a coherent model for (meta)data representation and storage >>4) will run on a wide variety of systems >>5) will run efficiently even on modest hardware >>6) in as much as possible, encourage and/or enforce the development of >>high-quality, versatile and maintainable code >>7) encourage/enforce separation of package metadata from specific build >>steps and algorithms >>8) allow for delivery of feature set that meets or exceeds expectations >>of existing user community >> >>design goals: >> >>1) reflect the sensibilities of "ports" system designs >>2) provide an easy-to-understand developer API >>3) provide an open, transparent architecture that reflects UNIX design >>philosophy >>4) In every way possible, program should be malleable to allow >>conformation to user needs and expectations, >>both interface as well as the specific actions performed by the program. > > > implementation goals: > 1) Support distfile renaming or distfile subdirectories or both to solve the > name-clash problem. > 2) Support useflag and slot dependencies as layed out by carpaski before and > which will probably come into the current portage. > 3) A full dependency tracker that can use the USEFLAGS from compile-time > instead of check-time to determine dependencies and stale packages. (Should > make depclean work) > 4) Support partial overlap of same-version/same-package packages. This would > require some extra variable like EXTRASLOT (for example php would specify > a value like apache2 for the apache2 module and apache1 for the apache1 > module). This variable can be determined at the compilation time based on > other parameters. The package database needs some name mangling (shouldn't > be a big problem). Further there needs to be some overlap detection. What > this would mean is that at the moment a second package of the same version > but with a different EXTRASLOT would be merged, the overlapping filenames > would be collected. Those would go in a general package. The ones from the > original package that do not overlap go to a new package specific to that > EXTRASLOT, and the files that are new go into the package with the new > EXTRASLOT. > > Why is this important. It allows for a package like php to be compiled as > both a plugin to apache1 as to apache2 without any difficulties. It is also > the solution for modules like alsa and nvidia drivers, and it eases > cross-compiler installation. > 5) Make the ebuild format as extendable as possible (without breaking all > current ones) to allow for future enhancements. > 6) (sidestep) Make a clear system for specifying the locales that should be > built, and if a specific locale needs to be chosen, what is the priority > list for that. This will make locales in things like kde and openoffice a > lot easier, but it also should be used by glibc and other ebuilds. I've got something that should be in the new portage. It needs to be able to download source tarballs in a separate thread while compiling is happening to speed the overall process, much like apt-get for Debian. -- Andrew Gaffney -- gentoo-portage-dev@gentoo.org mailing list