Re: Any volunteers for lintian co-maintenance?
Hi Niels,
at first sorry for my late answer.
At Thu, May 09, 2024 Niels Thykier wrote:
> You are welcome to quote me in public, though I feel it will not help your
> cause. This reply is in private to you, so you can choose whether you want
> to quote me.
I think any answer should be discussed.
> I agree with the sentiment that important Debian tools would ideally be
> co-maintained. However, in the passing years, I have started to feel a
> disconnect with lintian, its direction and what I would like to see. I no
> longer use lintian and I am fundamentally not interested in picking up
> lintian anymore - neither as a user nor as a contributor. I have even
> uninstalled it from my machines. For now, I still "allow" it in my salsa-ci
> pipeline but my patience with it is thin.
This is not the first message I've read about insufficiencies in lintian.
That's why I initially brought up this topic. I consider a tool that checks
conformance to our policy essential. Therefore, I think it is important to
discuss critical points as soon as I become aware of them. Lintian has saved
me from countless mistakes in the past, and I heavily rely on it in my
packaging work. I use it after every package build, as well as in Salsa CI.
> For me, lintian fails in all roles it has. It is not a good tool for newbies
> to get help, since it can only test build artifacts. As an example, your
> feedback look is a full package build followed by unpacking the package just
> so lintian can tell you have a typo on line 4. That is a massive waste of
> resources - notably developer time and mental bandwidth.
I understand your point about having a tool that checks the debian/ dir for
issues like spelling errors, binary files in the upstream source, and other
concerns right within the packaging tree before the build starts. However, I
don't understand why you mention newbies in this context.
> It also fails as an archive QA tool in my view since the FTP masters have
> been unwilling to upgrade to any recent version of lintian.
Perhaps a ftpmaster could explain this in detail. As far as I understand,
it's also a DSA issue. All packages are obtained from stable. I agree that
this does not make sense for a policy checker of packages targeting
unstable. Picking Lintian from backports or implementing some serviщe
featuring latest lintian might be alternatives, but it's not my task to
decide this.
> I think FTP
> master's argument lies with the very poor performance in certain corner
> cases that adversely affects larger packages (like linux).
I did not read this argument but it would be great to hear some educated
opinion.
> As a consequence,
> people now get auto-rejects when uploading because lintian on the FTP master
> server does not produce the same output as current lintian in stable or
> newer.
I think its a bit unfair to blame lintian about the fact that its old
versions do not do a proper job when it comes to checking newer packages.
> For the record, I support the FTP masters here since the performance was
> quite horrible at some point (might be fixed, might not be) and that would
> just block benign uploads. In fact, I would go so far as to say that the FTP
> masters should remove lintian from their upload checks (partly because of
> this, partly because only source packages are reliably checked which neuters
> the original point of adding lintian to the upload queue).
I would love to hear some ftpmaster opinion to avoid speculation about this
topic.
> The latter half (archive-wide qa + performance + trust) might be fixable
> with a dedicated effort and then a lot of lobbying to restore's people trust
> in lintian.
As far as this thread has shown there are some people who do not share your
opinion and as far as it concerns me my trust into lintian is not broken.
> But that is a lot of work, and it will not solve the former
> (feedback cycles). The former requires a completely different mindset and
> scope for the tooling.
I'm convinced that we need a tool to check the final build result. Lintian
was written for this purpose, and despite its performance issues, it does a
good job IMHO. I agree with you that adding the feature to check the source
tree would be a significant enhancement. I would welcome it if Lintian
received this feature or if a new tool could fulfill this additional role.
> To that end, I have decided to put my effort into `debputy` where I recently
> added support for linting *with* quickfixes, reformatting and editor support
> (the latter via LSP).
I admit I'm very curious about debputy since all I've read about so far
sounds very interesting. Unfortunately I'm lacking the time to test it.
BTW, totally unrelated to the lintian topic: To my package maintainers
perception you are the only developer of debhelper. Feel free to contact me
if you are not happy about this situation. I'm personally always concerned
if essential tools are maintained by single person "teams".
> I think that a much better approach to half of the
> issues that lintian emits
IMHO this is the point: We need lintian for "the other half" in any case
and to cover this we need people who keep on caring for lintian - at least
as long as we do not have anything better.
> and helps both newcomers and long term
> contributors to be much more productive.
>From my point of view I would not make the distinction between newcomers and
long term contributors. IMHO the problems you state are perfectly
orthogonal to the knowledge level of the lintian user.
> Especially for the editor support
> related parts, where people get instant feedback both on issues and the fix,
> automatic reformatting on save and completion suggestions. None of which
> lintian or wrap-and-sort are capable of.
If you ask me personally I'm absolutely happy about a policy checker that
simply reports issues. I'm fine with firing up an editor in some other
terminal and be done. Maybe I'm missing your point but for me that's a
non-issue. Or is your comparison with wrap-and-sort rather targeting at
some tool that automatically fixes the issues it has found and I can check
the changes afterwards with `git diff`? Or something like the janitor tools
that even commit changes?
> If I am successful, then lintian can specialize its efforts into issues only
> visible in packaged artifacts and thereby reduce it scope a bit.
Perfect. I'd love to have some policy checking at "the right point in
time". I'd love to support this but as far as I understand even your
suggestion does not spare the work of fixing lintian itself. The problem
that motivated me to my initial mail to ask for help on lintian was about
packaged artifacts and we need to keep an eye on this - no matter how nifty
things we do before.
> In that
> sense, my work might be a (minor) help to the Lintian team on the assumption
> they are willing to specialize more.
I personally can't imagine that lintian maintainers insist on doing work
that is done by someone else in some more appropriate way. My personal
opinion about the people who grabbed up the pieces that were left after some
problematic time is that they are very sane and open for any constructive
discussion. I'd happily stir such discussion (even if I feel myself not
very competent in technical details).
> But even if I am not successful with
> `debputy`, I cannot imagine I would consider returning to lintian. It does
> not scratch my itch and years of issues (some of which are still unfixed)
> have made me not want to have anything to do with the tool.
Well, we are all volunteers and for sure nobody intends to convince you to
work on anything you don't want to. But anyway I read from your mail that
you see some need for lintian being maintained. The fact that there are
issues unfixed for years was the reason for my initial mail. I keep on
hoping that it might lead to some new contributors.
Given your very interesting input we actually need people who are able to
dedicate quite some time on restructuring lintian in a way that respects the
fact that some checks can be done / are done by some other tool on source
level. Alternatively lintian itself could be modularised to rather do what
you want.
> Best of luck to Axel and anyone joining him to stop the bleeding. I do hope
> they are successful, since lintian still have valuable features for Debian
> as a whole that can be salvaged.
Thank you for stating this explicitly.
> But I am not going to be the "hero" that
> salvages that mess. If I am going to do heroics in this area, then it will
> be related to `debputy` with the aim to enable us to spend less mental
> bandwidth on daily packaging work.
That's cool and thanks for all the work you are putting in our packaging
infrastructure.
> PS: In my view, the bleeding of lintian's quality started long before Axel
> joined the lintian maintenance team and I do not fault Axel for being unable
> to stop the bleeding. In my view, only a hero could have "managed" that at
> the expense of their mental health.
Thanks a lot for your mental support to Axel which I confirm from my side.
To draw some conclusion out of the discussion: We need to enhance the way
we are checking our packages for conformance with our policy. You made
clear that quite a part can be done at source level. I'm not fully sure
whether your main focus is on the time inside the build process or the
editing features you mentioned. It is also not clear to me whether you are
questioning the general architecture like for instance the rule sets that
are in /usr/share/lintian/data. IMHO this is a valuable set of rules that
can be used by alternative tools as well. Do you agree with this or not?
As I wrote in my other mail in this thread[1] I could imagine some policy
checker step after dh_clean. When thinking twice about it another step
could be done before dh_builddeb which could detect lots of issues before
the package is built and can save the unpackaging step. Are you targeting
at this as well?
Kind regards and thanks a lot for your inspiring input
Andreas.
[1] https://lists.debian.org/debian-devel/2024/05/msg00162.html
Reply to: