From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27614 invoked from network); 15 May 2004 06:55:26 +0000 Received: from smtp.gentoo.org (128.193.0.39) by eagle.gentoo.oregonstate.edu with DES-CBC3-SHA encrypted SMTP; 15 May 2004 06:55:26 +0000 Received: from lists.gentoo.org ([128.193.0.34] helo=eagle.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.24) id 1BOt4w-0008Il-3B for arch-gentoo-portage-dev@lists.gentoo.org; Sat, 15 May 2004 06:55:26 +0000 Received: (qmail 5050 invoked by uid 50004); 15 May 2004 06:55:25 +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 19456 invoked from network); 15 May 2004 06:55:24 +0000 Message-ID: <40A5BDB9.20800@skylineaero.com> Date: Sat, 15 May 2004 01:50:33 -0500 From: Andrew Gaffney User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7rc1) Gecko/20040503 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-portage-dev@lists.gentoo.org References: <40A193B5.9080206@skylineaero.com> <200405130125.45541.jstubbs@gentoo.org> <40A598A4.8000109@skylineaero.com> <200405151514.26131.jstubbs@gentoo.org> In-Reply-To: <200405151514.26131.jstubbs@gentoo.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-portage-dev] building dependency tree X-Archives-Salt: 40c04f04-f00e-4369-9a2f-ae7546afb937 X-Archives-Hash: b2806e404970648f6fe6ada6b950f135 Jason Stubbs wrote: > On Saturday 15 May 2004 13:12, Andrew Gaffney wrote: > >>>Jason Stubbs wrote: >>> >>>>On Wednesday 12 May 2004 12:02, Andrew Gaffney wrote: >>>> >>>>>>I am writing a Perl program that does the same thing as 'emerge'. Yes, I >>>>>>started a thread about this on -dev about 6 months back, but I'm better >>>>>>prepared to do this now. I've already written functions that: >>>>>> >>>>>> * Build a list of USE flags from /etc/make.profile/make.defaults, >>>>>>/etc/make.conf, and $ENV{USE} >>>>>> * Build a list of masked packages from >>>>>>/etc/make.profile/package.(un)mask and /etc/portage/package.(un)mask >>>>>> * Build a list of matching ebuild versions from a >>>>>>'>category/package-version' type string taking masked packages into >>>>>>account * Extract the DEPEND line from a particular ebuild >>>>>> * Parse a DEPEND line using active USE flags and build a list of >>>>>>needed packages >>>>>> >>>>>>I'm starting work on the code that generates the actual dependency tree >>>>>>and then the list of packages to be installed. I don't have any Python >>>>>>skill, so I don't think that reading the code will help me much. Can >>>>>>anyone who deals with the Portage code a lot give me a general >>>>>>breakdown of the way that 'emerge' generates the dependency tree and >>>>>>then the list of packages to emerge? >>>> >>>>As of .51: >>>> >>>>Initial startup: >>>>* Read configuration files >>>>* Scan system for installed packages and auto-enable use flags and >>>>virtuals * Create master configuration >>>> >>>>Dep calculation: >>>>* Is blocker? No? Continue... >>>> * Is a matching package installed? No? Continue... >>>> * Make record of blocked package and continue... >>>>* Resolve atom to package >>>>* Has package's already been added? Yes? Continue... >>>>* Add package and note its parent >>>>* Copy master configuration >>>>* Is binary package? Adjust USE flags from build-time. >>>>* Is source package? Adjust USE flags from package.use >>>>* Parse DEPEND and RDEPEND and resolve against USE flags >>>> -- deps in "|| ( foo bar )" deps get preference by being installed >>>>* Calculate deps for each atom parsed, with parent as this package >>>>* Parse PDEPEND and resolve against USE flags >>>>* Calculate deps for each atom parsed, with no parent >>>> >>>>Order resolution: >>>>* Find first added package that has no parents >>>>* Add package to order and remove from tree >>>>* Continue... >>>> >>>>There are a number of problems in this logic, some of which you and >>>>Pieter have noticed. The ones you have mentioned, I've fixed in a >>>>complete rewrite. To fix the main flaws (package only gets the parent >>>>from when it is first added, and PDEPENDs having no parents) is next on >>>>the agenda but is quite difficult. >>> >>>You've already done a complete rewrite of the dependency resolver? > > > Yes and no. I started from scratch but used almost exactly the same logic. I > guess you could almost call it refactoring. Have a look at: > http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage-mod/portageapi/?root=gentoo-src > > Of interest to you, will probably be dep.py. Even if you do not understand > python, the logic should be fairly clear (I hope!). The only real change from > the above logic is that installed packages (including their original USE > flags and *DEPENDs) are also taken into account. I'll have to take a look at it. If anyone wants to take a look at my code (and maybe give me a few suggestions), the (almost) latest working version can be accessed at . It currently operates the same way 'emerge -ep' would. It doesn't generate the exact same packages to install as Portage, but it is pretty damn close. -- Andrew Gaffney Network Administrator Skyline Aeronautics, LLC. 636-357-1548 -- gentoo-portage-dev@gentoo.org mailing list