From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19615 invoked from network); 15 May 2004 06:16:17 +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:16:17 +0000 Received: from lists.gentoo.org ([128.193.0.34] helo=eagle.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.24) id 1BOsT3-0001nR-6h for arch-gentoo-portage-dev@lists.gentoo.org; Sat, 15 May 2004 06:16:17 +0000 Received: (qmail 599 invoked by uid 50004); 15 May 2004 06:16:16 +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 18517 invoked from network); 15 May 2004 06:16:16 +0000 From: Jason Stubbs To: gentoo-portage-dev@lists.gentoo.org Date: Sat, 15 May 2004 15:14:21 +0900 User-Agent: KMail/1.6.2 References: <40A193B5.9080206@skylineaero.com> <200405130125.45541.jstubbs@gentoo.org> <40A598A4.8000109@skylineaero.com> In-Reply-To: <40A598A4.8000109@skylineaero.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200405151514.26131.jstubbs@gentoo.org> Subject: Re: [gentoo-portage-dev] building dependency tree X-Archives-Salt: 09023cb4-a9d2-4370-add3-77c6872c6bcc X-Archives-Hash: 75c686743bbdea8062ae67a58ce6ed0a =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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=20 guess you could almost call it refactoring. Have a look at: http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage-mod/portageapi/?root=3Dge= ntoo-src Of interest to you, will probably be dep.py. Even if you do not understand= =20 python, the logic should be fairly clear (I hope!). The only real change fr= om=20 the above logic is that installed packages (including their original USE=20 flags and *DEPENDs) are also taken into account. Regards, Jason Stubbs =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iQCVAwUBQKW1P1oikN4/5jfsAQLrNgQArwpCmI3DQUHcLhDygRmX7WSl7d55KcQb jo/F6f+lROsQHYz6xFhktiUpvP8j6QalRDtF0c5zpdnUaSGzUZPBqd2Oqh1bjl78 tQbC5IbEw2myFLDNu1/DauSr//IsReFI86wDapjpGOkk6vmqE9LrZZW9TLCgA9UY dvdy3eWMj6c=3D =3Do4F2 =2D----END PGP SIGNATURE----- -- gentoo-portage-dev@gentoo.org mailing list