As previously discussed on the list, I've added a new framework for handling data collection about packages. Currently, the functionality is fairly limited, but the infrastructure is now in place and we can start growing it.
Every check script now gets a third argument, which is a Lintian::Collect object (well, actually either a Lintian::Collect::Source object or undef right now, but eventually a Lintian::Collect::Source, Lintian::Collect::Binary, or Lintian::Collect::Udeb object, all of which inherit from Lintian::Collect). The idea is that any code that reads data from the lab should instead call methods in those objects, which abstracts out the interface to the lab. The main immediate benefit is that the methods in the Lintian::Collect objects will cache data in memory, so the twenty times that we read fields/version while checking one package will become only one file read and then memory accesses. However, down the road, this opens the possibility of doing away with the collect scripts if we want to and just using this object to hold the same data. There is POD documentation for the new modules; take a look and let me know what you think. Given that this is an infrastructure change, I think this warrants a version bump, and I'd like to propose that we change the version numbering of Lintian at the same time. Currently, all we're ever doing is incrementing the third version number of the package. Should we switch to just using two versions; in other words, make the next version 1.24, the version after that 1.25, and so forth? Then we can do major version bumps for backward-incompatible changes or for major changes (such as, hopefully, the summer work on tag classification). What do people think? -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
