From: Jason Stubbs <jstubbs@gentoo.org>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] building dependency tree
Date: Sat, 15 May 2004 15:14:21 +0900 [thread overview]
Message-ID: <200405151514.26131.jstubbs@gentoo.org> (raw)
In-Reply-To: <40A598A4.8000109@skylineaero.com>
-----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
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.
Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iQCVAwUBQKW1P1oikN4/5jfsAQLrNgQArwpCmI3DQUHcLhDygRmX7WSl7d55KcQb
jo/F6f+lROsQHYz6xFhktiUpvP8j6QalRDtF0c5zpdnUaSGzUZPBqd2Oqh1bjl78
tQbC5IbEw2myFLDNu1/DauSr//IsReFI86wDapjpGOkk6vmqE9LrZZW9TLCgA9UY
dvdy3eWMj6c=
=o4F2
-----END PGP SIGNATURE-----
--
gentoo-portage-dev@gentoo.org mailing list
next prev parent reply other threads:[~2004-05-15 6:16 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-12 3:02 [gentoo-portage-dev] building dependency tree Andrew Gaffney
2004-05-12 5:14 ` Pieter Van den Abeele
2004-05-12 6:42 ` Andrew Gaffney
2004-05-12 7:59 ` Pieter Van den Abeele
2004-05-12 14:43 ` Andrew Gaffney
2004-05-12 15:02 ` Pieter Van den Abeele
2004-05-12 15:14 ` [gentoo-portage-dev] /etc/make.profile/use.defaults (was: building dependency tree) Andrew Gaffney
2004-05-12 15:19 ` [gentoo-portage-dev] /etc/make.profile/use.defaults Andrew Gaffney
2004-05-12 15:43 ` Pieter Van den Abeele
2004-05-12 15:44 ` Andrew Gaffney
2004-05-12 16:03 ` Pieter Van den Abeele
2004-05-12 16:08 ` Andrew Gaffney
2004-05-12 16:33 ` Jason Stubbs
2004-05-12 16:39 ` Andrew Gaffney
2004-05-12 17:28 ` Jason Stubbs
2004-05-12 16:25 ` [gentoo-portage-dev] building dependency tree Jason Stubbs
2004-05-15 4:12 ` Andrew Gaffney
2004-05-15 6:14 ` Jason Stubbs [this message]
2004-05-15 6:50 ` Andrew Gaffney
2004-05-15 7:06 ` Jason Stubbs
2004-05-15 15:31 ` Andrew Gaffney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200405151514.26131.jstubbs@gentoo.org \
--to=jstubbs@gentoo.org \
--cc=gentoo-portage-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox