On 2011-05-30 02:11, Niels Thykier wrote: > Hi >
Hey,
I have invoked "do-cracy" on this (though I am still option to
suggestions on this) and here is what I got so far.
> I have been looking at #460350 (plus clones) and was thinking maybe we
> could do something similar to dpkg-source and its
> debian/source/{local-,}options files. That is, we allow options to be
> listed in lintianrc (without leading "--" and only in long-form etc.)
>
I have been using this approach; the prototype only accepts a very small
(and not necessarily useful) subset of the boolean options.
Unfortunately --display-info is not one of them, as it is internally
mapped as a -L option.
The options supported by this patch are:
* info
* display-experimental
* no-override
* show-overrides
There is a little print(f) debug to STDERR that informs you what the
final value of these options are. I will remove that before merging
this into the master branch.
> Since lintianrc is currently used for setting variables, I suggest we
> keep backwards compatibility; any line starting with "LINTIAN_" will be
> read as an "old" variable and let it be translated to the relevant
> option (e.g. LINTIAN_ROOT -> root).
>
No changes here (namely because the affected parts are not boolean options).
> Format changes of lintianrc aside, we will also need to refactor the
> frontend. Here I propose that we delay interpretation of options (save
> for stuff like --cfg); the exact idea I had in mind was to stuff all
> options (with value) into a hash (GetOptions can do that for us as I
> recall) and as we parse the lintianrc file, we will options from there
> to the hash (as appropriate).
>
So far there not been a need to really delay interpretation; since the
patch only deals with boolean values (all of which defaulted to
false/off); that being said, I do smell complications with the -L.
As far as I can tell --display-info is the only option that maps to
-L/--display-level; but --display-level is sensitive to the order. That
being said; I strongly suspect that the amount of people using -L is
very limited.
Asking them to add a >=wishlish to their display-level option instead
of using display-info in the config seems like a reasonable solution to
the order problem. Particularly we can disallow the usage of both
display-info and display-level in the config at the same time.
I think it makes sense to ignore display-level and display-info, if
either --display-info or --display-level was passed on command-line.
For the parsing of display-level in the config, I am thinking of using a
space separation, so:
-L ">=important" -L "+>=normal/possible" -L +minor/certain
becomes
display-level= >=important +>=normal/possible +minor/certain
I also think we should disallow the usage of dont-check-part,
tags-from-file, ftp-master-rejects, check-part and
suppress-tags{,-from-file} and rely on people to create profiles for that.
I would also disallow actions (unpack, check etc.) since I do not
really think they make sense to have in the rc file.
~Niels
0001-Prototype-config-options-for-some-bool-options-only.patch
Description: application/wine-extension-patch
