| 1 |
With the repoman rewrite stage2 code about to be merged into master. |
| 2 |
And a release including it to be made soon. I am going to start on |
| 3 |
stage3 of the rewrite. So... |
| 4 |
|
| 5 |
It is time to start painting a bikeshed about moving all possible |
| 6 |
check data to the tree. In that way small changes to things like |
| 7 |
the deprecated eclasses to scan for can be added to/or removed and the |
| 8 |
updates will propagate to everyone as they git pull the gentoo repo. |
| 9 |
|
| 10 |
So, here is my initial thoughts so far. |
| 11 |
|
| 12 |
We (portage team) discussed the possibility of making the data available |
| 13 |
for download via api.gentoo.org. But we decided it would be much |
| 14 |
better if that data was included in the repository. In that way it |
| 15 |
makes off-line work easier without having to deal with having a live |
| 16 |
connection to fetch the latest version of the data. It also then |
| 17 |
matches your current tree checkout. It could also make it easier for |
| 18 |
alternate repositories to establish their own QA data files. |
| 19 |
|
| 20 |
I'm thinking that we should establish a directory for the files |
| 21 |
containing the data for the checks being run. With the module systems |
| 22 |
now in place with the stage2 rewrite code. I was thinking that we |
| 23 |
should break up the data into logical files to go with the different |
| 24 |
scan modules present in repoman. If a new module is created, then a |
| 25 |
new data file may be created for it's dynamically changeable QA data. |
| 26 |
|
| 27 |
This also has the advantage that if a new app comes along that performs |
| 28 |
these same types of checks. It should be able to make use of this same |
| 29 |
data. |
| 30 |
|
| 31 |
|
| 32 |
So, where do we place this directory and what rules do we |
| 33 |
establish about it's modifications? |
| 34 |
|
| 35 |
location? : in the metadata dir alongside the install-qa-check.d |
| 36 |
directory? |
| 37 |
|
| 38 |
name of the directory? : repoman, qa-rules, qa-data, |
| 39 |
repo-qa-data, ... ideas? |
| 40 |
|
| 41 |
data format? : json (my favorite) |
| 42 |
compatible with many lanquages/interfaces |
| 43 |
is flexible to match various data types |
| 44 |
ie: dictionaries, lists, strings... |
| 45 |
is human readable/editable |
| 46 |
can be validated |
| 47 |
|
| 48 |
xml (PLEASE NO!) |
| 49 |
|
| 50 |
native python file (too language dependant) |
| 51 |
|
| 52 |
ini style (python configparser compatible) meh :/ |
| 53 |
|
| 54 |
other ideas? |
| 55 |
|
| 56 |
editing rules? : Similar to eclass modifications... email to the |
| 57 |
gentoo-dev list for review, possible objections. |
| 58 |
|
| 59 |
|
| 60 |
|
| 61 |
The current releases of portage/repoman would continue to use internal |
| 62 |
data. But this new data would need to precede a repoman release that |
| 63 |
uses it. Initially this stage3 code will continue to be developed in |
| 64 |
the repoman branch of the portage repo. It is also possible to test |
| 65 |
this git checkout code by establishing a symlink to the checkouts |
| 66 |
repoman command somewhere in your users PATH. Personally I named mine |
| 67 |
repom, and lives in my ~/bin directory. In that way I can easily |
| 68 |
switch between an installed repoman and the developing code to compare |
| 69 |
results to aid in debugging. |
| 70 |
|
| 71 |
-- |
| 72 |
Brian Dolbec <dolsen> |
Archives