Implementation of vendor specific data files
Hi,
I have been thinking some more on these vendor specific data files. In
my original proposal[1], I "conveniently" left out how we are going to
implement the proposed extension.
In the code, we tend to load data files as soon as a check/module is
loaded (during the 'require/use $check;'). The question is how are we
going to pass the "vendor information" to these places. First up, I
identified the following "uses" of Lintian::Data.
* Lintian::Architecture
- used by Lintian::Tags and checks/fields
* Lintian::Check
- used by various checks
* checks/*
I have come up with two basic ideas for how to handle this. The first
idea is to export the vendor information in %ENV like we do with
LINTIAN_ROOT. The second idea is to load the data files in a static
module initialization method after require/use is completed. Of the
two, I am preferring the latter.
The primary reason behind my preference is that the first solution
requires "magical" handling for some modules. We would have to first
load Lintian::Profile, load the profile and export the profile
inheritance info via %ENV before we would be able to load Lintian::Tags etc.
On the other hand, I am not much for static initializations of regular
modules[2]. For Lintian::Architecture, I am considering to turn it into
a class/object. For Lintian::Check, a static initialization might be
cleaner/easier.
As mentioned, of the two I prefer static inits to "use/require" magic.
That being said, if you got a 3rd (or even 4th) idea, I would like to
hear it.
~Niels
[1] http://lists.debian.org/debian-derivatives/2011/12/msg00008.html
[2] For the checks, I do not really have a strong objection towards
adding static init subs.
Reply to: