Re: [gentoo-portage-dev] building dependency tree

[Andrew Gaffney]

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 <http://locutus.homeip.net/dev/portage.pl>. 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@g.o mailing list