Re: Lintian as a static analysis framework
Niels Thykier <niels@thykier.net> writes:
> Occasionally I have found myself considering to write some tool to check
> for something that would require (e.g.) a Packages file[1] only to stop
> because I need to (re-)write a package extractor, a dsc or d/control
> parser, two of Lintian's collections and then my analysis code on top of
> that.
> Of course with my knowledge of Lintian's internals I could still soup
> together some code that would allow me to re-use (the parts of) Lintian
> (I need), but as implied - it would not be pretty.
Yes, it would be really nice to provide a good API to that sort of thing
and make it available beyond Lintian. There's a lot of generic work
that's much more broadly useful.
> A(nother) personal thorn in my side would be #262783; in my ideal world
> this ought fairly simple, but in reality it is very complex. Mostly
> because the frontend actually glues the Lab together with the
> collections and the checks. The frontend also peeks deep into the
> internal parts of the lab structure (to test for and mark collections as
> finished). To me this is a sign that our backend needs more work.
Currently, Lintian assumes that all relevant information is gathered into
the lab before doing anything, and then the check scripts generally assume
they can access the lab directly. Essentially, the lab becomes the "ABI"
exposed to the checks. One of the goals of Lintian::Collect when I
started writing that framework was to have it serve as the indirection
layer used to access the lab. In other words, only Lintian::Collect and
the parts of Lintian that generate the lab would know about the structure
of the lab, and all check scripts would only access Lintian::Collect
interfaces. That would allow us to swap out any lab structure without
changing any of the checks, or support multiple different lab structures
(such as an unbuilt source package tree).
> On the other hand, I know it can be difficult to settle and maintain a
> public API. As far as I can tell, we have currently only officially
> committed ourselves to the frontends and the profiles + the (names of)
> the tags, checks and the collections. Everything else we can basically
> break and smash as we much like as long as we fix it before we hit
> release (which I admit is nice from a developer's point of view).
Yes. But I think the Lintian::* packages have also been fairly stable.
We may not be able to promise an ABI to everyone going forward
indefinitely, but we've not had many ABI breaks in the modules we've moved
into Lintian::*.
> That being said, I could see us commit to a liblintian-perl[2] that
> would for starters provide things like Lab, Lab::Package, the
> collections and Lintian::Collect{,::Binary,::Source,::Changes} (possibly
> moving Lab + Lab::Package under the Lintian:: prefix first).
Yeah, we should move everything into our namespace. And yes, this was one
of the things that I was hoping to do. We could even just move everything
in lib into it and finish fixing the namespace (there isn't that much left
in the wrong namespace), and just be clear in the module documentation
which pieces are considered stable and which pieces may change a lot.
> As we mature other things (or people request it) we could migrate more
> and more of lib/ into liblintian-perl.
> As for the test suite code, I would mature it a bit more and then
> refactor it into an external package to avoid circular
> build-dependencies between Lintian and javatools (javahelper) if possible.
That makes sense to me.
> Obviously, these changes would very likely fall under the "Hard
> projects" listed on [3], but I think we would do ourselves and the
> Debian project a favour in the long run by doing this.
Definitely.
One of these days, I'll get some more free time and will be able to start
helping again.... :)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: