[gentoo-dev] Repoman rewrite stage3. Migrate check data to the tree

[Brian Dolbec <dolsen@gentoo.org>]

With the repoman rewrite stage2 code about to be merged into master.
And a release including it to be made soon.  I am going to start on
stage3 of the rewrite. So...

It is time to start painting a bikeshed about moving all possible
check data to the tree.  In that way small changes to things like
the deprecated eclasses to scan for can be added to/or removed and the
updates will propagate to everyone as they git pull the gentoo repo.

So, here is my initial thoughts so far.

We (portage team) discussed the possibility of making the data available
for download via api.gentoo.org.  But we decided it would be much
better if that data was included in the repository.  In that way it
makes off-line work easier without having to deal with having a live
connection to fetch the latest version of the data.  It also then
matches your current tree checkout.  It could also make it easier for
alternate repositories to establish their own QA data files.

I'm thinking that we should establish a directory for the files
containing the data for the checks being run.  With the module systems
now in place with the stage2 rewrite code. I was thinking that we
should break up the data into logical files to go with the different
scan modules present in repoman.  If a new module is created, then a
new data file may be created for it's dynamically changeable QA data.

This also has the advantage that if a new app comes along that performs
these same types of checks.  It should be able to make use of this same
data.


 So, where do we place this directory and what rules do we
establish about it's modifications?

   location? : in the metadata dir alongside the install-qa-check.d
               directory?

   name of the directory? : repoman, qa-rules, qa-data,
                            repo-qa-data, ... ideas?

   data format? : json (my favorite) 
                        compatible with many lanquages/interfaces
                        is flexible to match various data types
                          ie: dictionaries, lists, strings...
                        is human readable/editable
                        can be validated

                   xml (PLEASE NO!)

                   native python file  (too language dependant)

                   ini style (python configparser compatible) meh :/

                   other ideas?

   editing rules? :  Similar to eclass modifications... email to the
                     gentoo-dev list for review, possible objections.



The current releases of portage/repoman would continue to use internal
data.  But this new data would need to precede a repoman release that
uses it.  Initially this stage3 code will continue to be developed in
the repoman branch of the portage repo.  It is also possible to test
this git checkout code by establishing a symlink to the checkouts
repoman command somewhere in your users PATH.  Personally I named mine
repom, and lives in my ~/bin directory.  In that way I can easily
switch between an installed repoman and the developing code to compare
results to aid in debugging.

-- 
Brian Dolbec <dolsen>