Simplifying lintian frontend
Hi,
I have been playing with the thought of simplifying the frontend. Not
only for ourselves, but also for the users. It is my belief that
lintian has a lot of features that nobody except "power-users"[1] use.
And even those people only use a few of them (and do so, only raringly).
Some things I would like to see gone (rationale explained below):
* All "actions" (--check, --unpack, --setup-lab ...)
* All "package selection options" and lab-query support
* --root / LINTIAN_ROOT
* "Keep-going on error"-semantics
Some things I would like to see changed:
* ad-hoc config parser replaced with an INI-like file parser
## On removing all "actions": First off, lintian defines the following
as actions:
-c, --check check packages (default action)
* -C X, --check-part X check only certain aspects
* -F, --ftp-master-rejects only check for automatic reject tags
-r, --remove remove package from the lab
-R, --remove-lab remove static lab
-S, --setup-lab set up static lab
* -T X, --tags X only run checks needed for requested tags
* --tags-from-file X like --tags, but read list from file
-u, --unpack only unpack packages in the lab
* -X X, --dont-check-part X don\'t check certain aspects
I have marked some entries with *, which I believe are not actually
actions (but more like "tag-selection"). In fact, -F is not even
implemented as an "action" (meaning that -F can be used together with
another action despite what the documentation says).
That leaves -c, -r, -R, -S and -u as actual actions. Of these, all
average users will generally just use "-c" (and will do so implicitly).
I recognise that some of these options are useful for us to test
Lintian (or for use on lintian.d.o), but I think we would benefit from
making a dedicated frontend for those operations.
For the "rest", I think retaining those as (non-action) parameters would
make sense.
## On removing lab-query and package selection options: No average user
will never use these. They make sense with a static lab, which implies
a userbase limited to at most 10 people (a.k.a. the "power-users"). I
think this functionality if retained should be moved to a different
frontend.
## Removing support for "--root" and LINTIAN_ROOT: These are intended
for running lintian directly from the source tree. Again, not for the
average user. Also, in its current form --root allows you to combine
any lintian frontend with any LINTIAN_ROOT, which breaks in all sorts of
fun ways when the two pieces are not compatable.
I suggest we pull these and have the frontend(s) use a hard-coded root
(inserted at install time like the version). In the absence of this
path, the frontend will assume it is run from a source tree and find
LINTIAN_ROOT as:
my $root = realpath(dirname(dirname(__FILE__)));
That way, the frontends from the source tree will also "just work"(tm)
without any fiddling or need for setting up a wrapper to set
LINTIAN_ROOT. For anything that does not need to know about
--include-dir, we can now do that plus "unshift @INC, $root" in a BEGIN
block and start importing Lintian modules at compile time.
For stuff that needs to support --include-dir, we can still do that in
BEGIN{} but it takes a bit more code (but I will come back to that in a
moment).
## Removing "keep-going on error": Currently, Lintian will trap errors,
print a warning and then continue. The average user do not need that, I
do not need that when developing the code[2] and quite a bit of code can
go away with "error implies stop" instead of "trap error, remember exit
code and continue"[3].
But we currently rely on it on lintian.d.o where packages can just
"disappear" in the middle of being processed. I think we should "fix"
that sometime, but not necessarily now. So I am fine with having a
frontend for "lintian.d.o" that has "keep-going" semantics.
## Changing the config format to an INI(-like) format: Currently, we
have an ad-hoc file parser for the lintianrc file. It is not too bad,
but I think changing it into an INI format would beneficial. For one,
we can now have frontend-specific sections (or maybe "purpose"-specific
sections like git's config).
The choice of the INI-format is mostly born from two reasons; it has
parsers readily available and it should be backwards compatable with our
current format (possibly, given the right parser). Personally, I am
leaning towards using (or making a subclass of) Config::INI::Reader at
the moment. I do not consider Config::Any a viable alternative until
error handling is possible[4]. That said, any alternatives with
"reasonable"/well-defined error semantics are definitely welcome.
So in summary, I think we should cut out some of the "special use-case
only" features and either drop it completely or stuff into one (or more)
new frontend(s).
As a small example of what we could be looking at, I have started a a
small branch for prototyping a new frontend[5]. It currently features a
rewritten lintian (called lintian-ng in the lack of a better name),
which is intended to target the "average user".
At the moment, it only 1/4th of the original lintian frontend and
supports quite a few of its features. Notable features omitted are
config parsing, version information, tag/check selection and "find stuff
to process if not given"[6].
Comments, feedback, suggestions, critique or even just "don't care, so
whatever floats your boat" are more than welcome.
~Niels
[1] Whom I believe would be limited to you and yours truly. In other
words, the developers of Lintian(-like tools or Lintian "add-ons").
[2] A flat "code is broken, STOP" is less frustrated than the current
while (not $done) {
...;
print STDERR "Here is another warning\n";
print STDERR " - you broke pretty much everything, didn't you?";
}
[3] That is, most of the code like:
eval {
code_that_might_die();
};
if (my $err = $@) {
warning($err);
$exit_code = 2;
next;
}
becomes:
code_that_might_die();
[4] https://lists.debian.org/debian-lint-maint/2013/04/msg00038.html
[5]
http://anonscm.debian.org/gitweb/?p=users/nthykier/lintian.git;a=shortlog;h=refs/heads/prototype/lintian-ng
[6] Basically this part of frotend/lintian:
# If debian/changelog exists, assume an implied [...]
# (or "../<source>_<version>_source.changes").
if ( -f 'debian/changelog' ) {
my $file = _find_changes();
push @ARGV, $file;
$ok = 1;
}
Reply to: