Hi
Yesterday in #debian-qa, I chatted with Paul Wise and the idea came up
that Lintian should be a framework that others could use as a basis for
their own analysis - particularly when these analysis would conflict
with some of the Lintian design goals (namely we try to be independent
of the system state).
When I write "Lintian should be a framework", feel free to read it as
"refactor a framework out of Lintian, on which Lintian will depend and
the framework will have a separate name".
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.
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.
To be honest I have even considered factoring our (new) test suite code
so packaging tools like debhelper and javatools can (ab)use it for their
own test suite.
The idea of template packages where you only have to mess with a bare
minimum to get a package is nice and I could have used that for
javatools to catch regressions a number of times now, but I do not feel
like re-inventing the wheel either.
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).
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).
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.
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.
~Niels
[1] Or some other data that we in Lintian can never rely on being
present and up to date.
[2] Care must be taken here to ensure we keep the "git clone, hack, run"
property if we install the code in liblintian-perl under /usr/share/perl5.
[3] http://wiki.debian.org/Teams/Lintian
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e1583c6.3090...@thykier.net
--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e1583c6.3090...@thykier.net
