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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
