After today's release of portage-2.2.21, I merged the repoman re-write
code in to portage master branch. So, the code is functionally
identical to portage-2.2.21 with the exception of repoman. It is now
ready for more testing before it too is released in a normal portage
release. Please keep in mind that the current re-write code is
functionally not different the the old monolithic script. While the
code itself has been changed, The intent for this stage of the
re-write process was to not change functionality, but to break up the
code into a reasonable python structure. In so doing some code has
naturally been improved, but this code is to be considered in an interim
state only. There are many more changes to happen in the code base.
General plan:
Stage 1: break up the monolithic code into a reasonable python
structure. This included moving some code into a sudo plugin
type system within the same class it was moved to. This was
in preparation for stage 2.
*** We are here at this point. Please test this code as it will be
the only code patches will be accepted for from now on. The old
code is too different to be able to reliably rebase the rewrite
changes on. So, please check that any issues you find are not also
issues in the current releases, file any new bugs tagged with the
9999 version. It is possible to use the new code directly from the
portage checkout without being installed. Just create a symlink
from your users bin/ directory to the bin/repoman command in the
checkout (using a slightly different name). That will allow you to
run it from anywhere on your system your user has access to. It
will also let you keep your normal portage installed for performing
most tasks. It also lets you do back to back runs one testing the
re-write, the other, using the stable existing code to compare the
results with.
Stage 2: Create proper plugin systems for various sections of the code.
This includes one for all VCS (git, svn, hg, cvs,...) actions.
And one for all repository checks.
Possibly others... (to be determined). This will also allow
for better configurability. And should allow easier
addition/removal of checks.
# After this next stage is completed it too will be merged back
into master and a release made after suitable testing/debugging.
Stage 3: Re-factoring of the code to properly optimize it's actions,
add a configuration file(s), and other code improvements. It
will be at this stage that the API's will be finalized. It
will include moving the results tracking of the errors,
warnings from a simple list to namedtuple classes. This will
make it possible to add other front-ends to running repoman
other than the command line interface it comes with. This
will mean that a Q/A website frontend could be created that
returns the results to the pages as proper python data or
json converted data rather than parsing stdout which can be
buggy and need constant updates if the format changes.
Thank you :)
--
Brian Dolbec <dolsen>
