[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

New Lintian::Data abstraction



I started looking at adding support for checking doc-base categories and
decided that we're getting a bit heavy on long lists of data embeded in
Perl code or variable settings.  In general, the more separation between
code and data we can maintain, the easier lintian will be to maintain
going forward.

I'm going to add a new abstraction for dealing with this sort of list of
external data and a Lintian::Data module to handle it.  (The name is a
model that I'd like to move towards for all of the lintian Perl modules so
that eventually we can be agnostic about whether they're installed in our
own private library directory or in the regular Perl search path.)

To start with, the API is just:

    my $list = Lintian::Data->new('type');
    if ($list->known($keyword)) {
        # do something ...
    }

where type refers to a file named "type" in a new data directory in the
lintian root.  That file will list valid keywords, one per line, with
blank lines and lines starting with # ignored.

This will let us put all the doc-base sections in a file with a comment
saying where they came from and update them going forward without needing
to change lintian code.

In the future, an obvious enhancement to this layout that would let us
deal with more of our embedded lists would be to add a list of
space-separated attributes after the keyword and an interface to query
whether a keyword has a specific attribute and to return all keywords with
a specific attribute.  Then, for example, we could have a file named
doc-base/fields-main with contents:

    document required
    title    required
    section  required
    abstract
    author

and code like:

    my $main_fields = Lintian::Data->new('doc-base/fields-main');
    for my $field (sort $main_fields->with_attr('required')) {
        tag "doc-base-file-lacks-required-field", "$dbfile:$line", "$field"
            unless $sawfields->{$field};
    }

I'm not planning on doing this for the first round, though.

I'll do this just for the doc-base categories for right now so that we can
try out the interface and see if it makes sense, and not convert other
things until after this release.  Eventually, if this works out as I
hope, most or all of common_data.pm would be a candidate for moving.
(Being able to add comments about why each thing is listed seems very
useful.)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: