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

[Brian Dolbec]

On Thu, 10 Mar 2016 18:40:31 -0800
Patrick McLean <chutzpah@g.o> wrote:

> On Thu, 10 Mar 2016 18:30:07 -0800
> Brian Dolbec <dolsen@g.o> wrote:
>
> >  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?
>
> That sounds reasonable to me, it is certainly metadata.
>
> >
> >    name of the directory? : repoman, qa-rules, qa-data,
> >                             repo-qa-data, ... ideas?
>
> Something not project name specific, so nothing about repoman. Perhaps
> something like "repo-checks", my personal vote would be make it a
> directory with the contents being merged (so repo-checks.d maybe?)
>
> >
> >    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?
>
> YAML - like JSON but made to be edited/read by humans (comment support
> is a big feature). Also valid JSON is valid YAML. Also can be
> validated just like JSON can.

OK, I just had a closer look at yaml.  It does look easier for humans
to edit and read.  And seems to have the same data type flexibility.
Maybe not quite as many languages have libs for it.  But I don't think
that is an issue for this data.


I also want to separate the repoman release from the main portage
release.  This will have several advantages.

    1) smaller portage install for installs that don't need repoman
    capabilities.

    2) Repoman can add extra dependencies as needed for things like
    pyyaml and xmlschema.  These deps would not be required for the
    base portage/emerge code.  Keeping a base install stage3 lighter
    and not complicate bootstrapping a stage1, stage2.

    3) They can be released indendant of each other as the need for a
    new release is desired/required.  While repoman will still be tied
    to the portage codebase.  Most of it's code use is via fairly
    stable API's.  So only when those API's change will there need to
    be a simultaneos release.

-- 
Brian Dolbec <dolsen>