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