[gentoo-portage-dev] [Patch] Repoman rewrite stage2 modularization conversion complete

[Brian Dolbec]

I have now pushed a fully rebased, properly sequenced commit history
to the repoman branch.  To be honest I think all the rebasing,
re-testing took as much time as the initial conversion and testing.
Anyway, I consider the branch now ready for final review.  Since there
are a total of 45 commits.  I am not sending them to the list at this
time.  They are available for review via the repoman branch at

https://gitweb.gentoo.org/proj/portage.git/log/?h=repoman

https://github.com/gentoo/portage/commits/repoman

or github pull request for commit order convienience

https://github.com/gentoo/portage/pull/22

But please try to follow our standard rules and reply with any comments
or code review to this email thread.  I can also generate the email
patches if necessary, but I fear they will just clog up your inbox.
There are some patches that are quite large like the vcs plug-in
conversion which could not be done piecemeal and still be able to run
the code to test.


Summary:

This stage now has three plugin system loops to process all the checks
and maintenance actions.  The three loops are currently hard-coded and
many of the checks must be run in a certain order as many of the
checks add or modify the dynamic data required by later checks.  I
will endeavour to create a complete wiki page on the new system when
approved, detailing how to create modules.  I will also generate a
table of dynamic data available and the modules responsible for
it.  In that way any modification to the modules run, added or removed
can be determined.

1) Primary pkg level checks
2) Ebuild level checks
3) Final pkg level summary checks

There are 2 primary plugin systems

1) The VCS plugin system
2) The Scan plugin system

All use the existing portage plugin system used in emaint and the new
sysnc systems.

The scan plugin modules can have functions that run in any of the three
loops.  They can also have more that one function that runs in any one
loop.  All functions in the loop will be run in sequence in the order
listed.  The plugin system runs the functions via reference, not name,
so the module lists the functions by reference.  The runInPkgs,
runInEbuild and runInFinal functions are designed in a way that allow
for the most flexibility and control by the module itself.  As such one
loop level function can control the actions of the next levels.  They
are not forced to be hard-coded.  Although, there are currently no
modules that use or need that ability at this time. 

Still to do in further rewites:

	Create a file or files to store easily edited repository data
	that can be included in the repo metadata.  In that way small
	changes can be done by maintainers without requiring a new
	repoman release because that data comes with the release.

	Make the plug-in checks loops configurable.  Then the checks
	run can be configured for the repo being checked.  All repos
	are not created equal and may have their own eclasses and
	eclass checks, etc..

	Continued code optimizations.  At this point many of the scan
	checks, etc.  have not undergone extensive changes.  Only what
	was necessary to fit the new structure.  Many could probably be
	optimised for better configure-ability and execution.
-- 
Brian Dolbec <dolsen>