Review of debusine's lintian related API

Hello Axel, Bastien, Lucas, and other members of the lintian and QA teams, it's been a long time that I have been interested in building some infrastructure to manage scheduling and distribution of Debian-related build, QA and data collection tasks to a network of worker machines. I called this

Bug#960154: Feed UDD with just-in-time packaging hints from Lintian

Hi, On Wed, 14 Apr 2021, Lucas Nussbaum wrote: > I think that in Debian, we would aim for a better separation between: > > A/ QA tools development, focused on getting the good tools to analyze > packages (output: tools, as Debian packages) > > B/ infrastructure that mass-process the archive

Bug#966368: lintian gets stuck when run by sbuild within rebuildd

Hi, On Mon, 27 Jul 2020, Chris Lamb wrote: > > In Kali, our build daemons run "rebuildd" with a build script that calls > > sbuild --run-lintian. Since lintian 2.85 (I believe 2.84.0 is not affected), > > the build process get stuck at the point when lintian is run. I see two > > lintian > >

Bug#966022: lintian: False positive on missing-depends-on-sensible-utils with commands like i3-sensible-pager

Hello, I just want to point out that the search for the "sensible-*" commands might be a bit too broad. It also finds the strings in /usr/share/lintian/overrides/i3-wm-gaps... Same issue in i3-wm in Debian: https://lintian.debian.org/sources/i3-wm/4.17.1-1.html Cheers, On Wed, 22 Jul 2020,

Bug#943525: Namespaces for Lintian Tags

Hi, On Wed, 20 Nov 2019, Felix Lechner wrote: > There are many motivations: Among those motivations, which one is the one that triggered this process and which one are there as "additional benefits" that you could identify to justify the change? > 1. Shortens tag names. I don't see that as a

Bug#920691: lintian gets stuck collecting info after failed objdump-info

On Sat, 02 Feb 2019, Niko Tyni wrote: > On Mon, Jan 28, 2019 at 07:01:52PM -0800, Felix Lechner wrote: > > Maybe the pending Perl commit 672eb451 will help? Details in #916313. > > FYI I've just uploaded perl/5.28.1-4 which fixes #916313. Thanks for the notice, I tried with that version of Perl

Bug#889991: Debian part of a version number when epoch is bumped

On Tue, 08 May 2018, Chris Lamb wrote: > Hi Raphael, > > > + tag 'latest-debian-changelog-entry-reuses-a-formerly-existing-version' > > Can you provide a quick description for this new tag? :) Info: All versions for a source package must be unique, even with a leading epoch stripped off.

Bug#889991: Debian part of a version number when epoch is bumped

On Fri, 09 Feb 2018 22:07:52 + Chris Lamb wrote: > Done: > https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=1cadac3c48bf361c2894d56f2ef6fdf28bc32e9e This commit does not really implement what was requested in this bug report. The desired logic is this one

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

Hi, On Tue, 08 May 2018, Mattia Rizzolo wrote: > > > I think this warning was not in place yet when you made that mistake. > > > > This warning was added in 2007 so it's likely I just missed it. > > I doubt you missed it. > latest-debian-changelog-entry-without-new-version is really what it >

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

Hi Chris, On Mon, 07 May 2018, Chris Lamb wrote: > I've just implemented this, but I notice that it overlaps with > > "W: latest-debian-changelog-entry-without-new-version" > > Do you think it's still worth adding (essentially) an "E:" version > of this? I would tend to be in favour, given

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

On Fri, 04 May 2018, Chris Lamb wrote: > Could you provide some concrete "good" and "bad" cases? I'm pretty > sure I know what you're after here but want to be 100% certain, > especially if we want this to be an "error". :) Good (in the context of this lintian tag, though I would have used

Bug#891555: Detect and warn about debhelper >= 11 instead of 11~ b-d

Hi, On Mon, 26 Feb 2018, Thomas Goirand wrote: > Currently, there's debhelper 11~bpo9+1 in Stretch. However, mostly everyone > build-depends on debhelper (>= 11), making it impossible to use the backported > debhelper without fixing the debhelper version of the software to backport. > > It'd be

Bug#762753: moreinfo

Control: tag -1 - moreinfo On Mon, 27 Oct 2014, Bastien ROUCARIES wrote: > Do you have some normative element about this tag? It's not hard to find: https://en.wikipedia.org/wiki/Canonical_link_element https://tools.ietf.org/html/rfc6596 And I agree that this is false positive that should be

Bug#889066: lintian should warn if the maintainer scripts include "chown -R" or "chmod -R"

Hi, On Fri, 02 Feb 2018, Chris Lamb wrote: > > In my case, I remember having touched many packages with dedicated > > users created and I expect this tag to have a very high false positive > > ratio > > Can you make this more concrete? (Or, perhaps, why is colord > vulnerable but your particular

Bug#889066: lintian should warn if the maintainer scripts include "chown -R" or "chmod -R"

Hi, On Fri, 02 Feb 2018, Chris Lamb wrote: > > you do not suggest any alternative (how do I fix change > > permissions/ownership securely?) > > Indeed, as the consensus is still not clear at this point. Do you > have any suggestions for such a text? Consensus? Has there been a broader

Bug#889066: lintian should warn if the maintainer scripts include "chown -R" or "chmod -R"

Hi, On Thu, 01 Feb 2018, Daniel Kahn Gillmor wrote: > "chown -R" and "chmod -R" are very hard to use safely Why ? > some debian maintainer scripts might be tempted to use them to adjust > file ownership to specific users. however, those scripts are > vulnerable to attack on kernels that do not

Bug#871575: lintian: maintainer-address-causes-mail-loops-or-bounces should be fixed to allow @packages.debian.org emails

Hi, On Thu, 10 Aug 2017, Chris Lamb wrote: > Hi Raphaël, > > > I believe that the check maintainer-address-causes-mail-loops-or-bounces > > should no longer refuse "*@packages.debian.org" in the Maintainer field. > > The regex is currently: > >/\@packages\.(?:qa\.)?debian\.org/i > >

Bug#865531: lintian: testsuite-autopkgtest-missing checks the wrong thing

Hi, On Thu, 06 Jul 2017, Niels Thykier wrote: > On Thu, 22 Jun 2017 14:45:52 +0200 =?utf-8?q?Rapha=C3=ABl_Hertzog?= > wrote: > > Package: lintian > > Version: 2.5.51 > > Severity: normal > > > > lintian complains with testsuite-autopkgtest-missing when debian/control > > is

Bug#865531: lintian: testsuite-autopkgtest-missing checks the wrong thing

On Thu, 22 Jun 2017, Raphaël Hertzog wrote: > lintian complains with testsuite-autopkgtest-missing when debian/control > is missing the "Testsuite" field but that field is usually not present > in the unpacked source package because it is automatically added by > dpkg-source to the .dsc when it

Bug#818962: [lintian] Proposed patches for php checks

Hi, On Wed, 20 Apr 2016, Ondřej Surý wrote: > I think the lintian should not allow dependency on phpX.Y-, but > only on php- (people can still override that), because we want > packages to transition between different PHP versions by default. > > I'll review Mathieu's patches tomorrow and update

Bug#799861: false positive in "source-is-missing" when dealing with .js

On Mon, 19 Oct 2015, Bastien Roucaries wrote: > Next version will be a little bit more clever. False positive are low > about 5% woth thé actual détection What next version are you referring to? lintian 2.5.38.1 gives me even more false positives on Django 1.8.7-1 now: E: python-django source:

Bug#799861: One more case of source-is-missing false positive with Django 1.8.5

I get this with python-django_1.8.5-1.dsc P: python-django source: source-contains-prebuilt-javascript-object django/contrib/admin/static/admin/js/SelectFilter2.js line length is 360 characters (>256) E: python-django source: source-is-missing

Bug#758425: lintian: add a check for outdated version constraints

On Sun, 17 Aug 2014, Johannes Schauer wrote: Lintian could check if any dependency on binary packages has an outdated version constraint. If the outdated version constraint is attached to an essential package, then the dependency can be dropped completely. This will then avoid useless

Bug#758425: lintian: add a check for outdated version constraints

On Fri, 29 Aug 2014, Johannes Schauer wrote: Hi, Quoting Raphael Hertzog (2014-08-29 21:16:06) If that is ever implemented, it must apply only on dependencies that can be parsed on the source's debian/control because I would not be happy to have warnings on library dependencies generated

Bug#758425: lintian: add a check for outdated version constraints

On Fri, 29 Aug 2014, Johannes Schauer wrote: - only check the manual dependencies from debian/control (and not those generated by dpkg-shlibdeps because those are legit) Definitely. - restrict the set of packages for which to warn to those that have to be translated (compilers). The

Re: Correct way of providing uncompressed data.tar

Hi, On Thu, 05 Dec 2013, Roland Stigge wrote: To implement a correct fix, Ben asked for a decision by dpkg maintainers, FTP team and policy. Basically, the question is if I think Guillem's position is rather clear, since he filed #718330 requesting support of data.tar in APT. I also agree with

Bug#612610: [lintian] may be time now

Hi, On Thu, 29 Aug 2013, Bastien ROUCARIES wrote: Is there a consolidated list of concerns about 3.0 (quilt) somewhere? Not to my best knowledge. The only technical concern that I'm aware of is that it doesn't work for the workflow of debia...@lists.debian.org, they like to use quilt to

Bug#679132: lintian: false positive on package-uses-local-diversion when --local and --package are not given

On Tue, 10 Jul 2012, Niels Thykier wrote: Actually, it sounds like it is a proper warning, since Squeeze (i.e. stable) still has 1.15.8.12. That means it could cause issues for people not upgrading dpkg before everything else (or for any package upgraded together with dpkg). Right. It's a

Bug#632556: checks/deb-format: allow data.tar.xz

On Sun, 03 Jul 2011, Ansgar Burchardt wrote: Hi, please allow data.tar.xz in addition to data.tar.(gz|bz2). Support in dak will be coming soon. FWIW this bug is blocking the deployment of XZ-compressed .deb since dak will reject those deb until a fixed lintian is uploaded to

The trigger in your Debian packages

Hello, you're maintaining a Debian package which provides a trigger file. Currently a package that activates a trigger is put in the triggers-awaited status where it doesn't fulfill dependencies. The trigger must first be processed and only then is the package considered as installed. I believe

Bug#626775: lintian: should accept any all in Architecture in .dsc and not trigger magic-arch-in-arch-list

Hi, On Sun, 15 May 2011, Russ Allbery wrote: I'm probably just reading a bit too much finality into next version of dpkg (1.16.1) will keep, but it can be a bit off-putting to get the feeling that dpkg's source code is authoritative for the meaning of Policy-standardized fields and the rest

Built-Using and lintian

Hi, your latest lintian commit is wrong, Built-Using is a field that appears in the binary packages, not in the source package. commit b7d9e253521b8641922a3b08091d7990d767db3a Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English)

Bug#618001: lintian: maintainer-script-lacks-debhelper-token is sometimes not reported when it should

On Sun, 27 Mar 2011, Niels Thykier wrote: I cannot reproduce the warnings when using debuild -S (-us -uc) on the version of this package in unstable with the lintian from git. The version in unstable has been fixed already, you should try with the version in snapshot.debian.org:

Bug#616493: lintian: Should know about the Multi-Arch field

On Fri, 11 Mar 2011, Niels Thykier wrote: I have added Multi-Arch to the list of known binary fields. I assumed it did not apply to udebs, changes and source packages, please correct me if I am wrong here. That's correct. (For dpkg, udeb are no different from deb and thus they are allowed

Package-Type not included in udebs

Hi, On Wed, 07 Apr 2010, Don Armstrong wrote: Anyway, I'd rather just make dpkg-dev special case udebs and not output the field to the binary, even if I think that will imply lose of automation and better integration among others, than a possible solution shoved down the d-i team throat

Bug#575059: Should Package-Type be included in udebs or not?

Package: tech-ctte (a change in lintian is triggering my request) On Thu, 11 Mar 2010, Cyril Brulebois wrote: following the instructions given by Frans in [1], I've written a tiny check to ensure I wasn't missing any occurrences in the bunch of udebs I'm currently adding. I guess it would be

Another lintian release for squeeze?

Hello, have you planned another lintian release for squeeze? I would like to see my debian/source/format related checks (#566820) merged in the lintian version that will be in squeeze. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Freexian : des développeurs Debian au service des

Bug#573088: Allow and recommend sha256sums control file

On Mon, 08 Mar 2010, Frank Lin PIAT wrote: Please find a patch attached that allow (and recommends) to provide sha256sums. (During a transition period, we encourage people to provide both SHA and MD5, so existing setup don't get broken). I'm not sure we should push for this right now. On the

Bug#528001: Bug#566820: lintian: Warn about missing debian/source/format, advise switch to new 3.0 source formats

tag 566820 + patch thanks Hi, On Tue, 02 Mar 2010, Russ Allbery wrote: Do you want a patch for this? If yes, should it be a new check file or do you want it integrated in one of the existing check file? At first glance, asking people to declare the source format explicitly seems like a

Bug#566820: lintian: Warn about missing debian/source/format, advise switch to new 3.0 source formats

Hi lintian maintainers, On Mon, 25 Jan 2010, Raphaël Hertzog wrote: As part of the plan to have the new source formats as the default formats in Debian I would like lintian to give a warning when debian/source/format doesn't exist, it could be named missing-debian-source-format. Do you want a

Bug#566820: lintian: Warn about missing debian/source/format, advise switch to new 3.0 source formats

On Mon, 25 Jan 2010, Goswin von Brederlow wrote: Raphaël Hertzog hert...@debian.org writes: We could also add a tag using-old-source-format that warns of specifying 1.0 in that file. Obviously this one should start among the pedantic tags but its importance might be increased over time

Bug#563685: lintian: check for files directly under /usr/share/mime/

On Mon, 04 Jan 2010, Jakub Wilk wrote: Package: lintian Version: 2.3.1 Severity: wishlist Please warn if a package ships files directly under /usr/share/mime/. Those files are meant to be automatically generated by triggers of the shared-mime-info package. Please also catch

Bug#563685: lintian: check for files directly under /usr/share/mime/

On Mon, 04 Jan 2010, Jakub Wilk wrote: Package: lintian Version: 2.3.1 Severity: wishlist Please warn if a package ships files directly under /usr/share/mime/. Those files are meant to be automatically generated by triggers of the shared-mime-info package. +1, I got bitten by this this

Bug#555331: [col] improperly fails with Invalid or incomplete multibyte or wide character

Package: bsdmainutils Version: 8.0.1 Severity: serious Since today I gets lots of lintian warnings (manpage-has-errors-from-man) on my dpkg builds because col fails with: col: Invalid or incomplete multibyte or wide character You can reproduce it by doing this: LANG=C man --warnings -E UTF-8 -l

Bug#545078: lintian: warn if symbol file contains tag but no build-dep on dpkg-dev (= 1.15.3~)

On Mon, 14 Sep 2009, Modestas Vainius wrote: Just grep possible source symbol file templates for tag specification and warn if no strict dpkg-dev build dependency exists. I'm not convinced that the requested check is really important (after all, it will be useless in squeeze+1 when that

Bug#534640: lintian should check that info files contains section and directory entry

On Fri, 26 Jun 2009, Raphaël Hertzog wrote: Since the upload of install-info to sid, packages installing info documentation should no more call install-info in their postinst. Lintian could check this, it's probably best to add this check only once debhelper has been fixed (see #534639). You

Bug#534640: lintian should check that info files contains section and directory entry

On Thu, 25 Jun 2009, Russ Allbery wrote: It's been there for quite a while. It needs to be modified so that passing --section to install-info isn't enough, but is there something more that it needs besides that, or some other problem with the existing Lintian check? No, I didn't knew about

Bug#525782: lintian: warn about #MISSING: ... in symbols files

clone 525782 -1 reassign -1 dpkg-dev retitle -1 dpkg-gensymbols should strip #MISSING lines in symbols files in .deb thanks On Mon, 27 Apr 2009, Paul Wise wrote: Please warn about symbols files containing #MISSING: ... It's not clear to me that they have to be stripped. They represent useful

Bug#506673: lintian: shlib-missing-in-control-file and symbols-declared-but-not-shlib wrong for libraries without versions

On Sat, 27 Dec 2008, Russ Allbery wrote: It does look like they can be represented in the symbols system because the symbols system doesn't have the separate version field and instead shows the complete SONAME. Is that correct? Right. happening somewhere. I've seen several different

Bug#506673: lintian: shlib-missing-in-control-file and symbols-declared-but-not-shlib wrong for libraries without versions

Package: lintian Version: 2.0.0 Severity: normal On libc6 in experimental I see: E: libc6: shlib-missing-in-control-file libpcprofile.so for lib/libpcprofile.so E: libc6: symbols-declared-but-not-shlib libpcprofile.so But since libpcprofile.so has no version in its soname it simply isn't

Bug#506697: lintian: invalid missing-build-dependency libmodule-build-perl

Package: lintian Version: 2.0.0 Severity: normal For some strange reason, the latest version of libmodule-build-perl doesn't work for zim and thus I added a Build-Conflict to force the usage of version of the module that is provided by perl-modules: Build-Depends: debhelper (= 5.0), perl-modules

Bug#484549: Patch to handle quilt series like

, and it was not always checking all *.dpatch files. Thanks for applying! -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ From c632887347cb0fefb73b2b0247881232c04570d7 Mon Sep 17 00:00:00 2001 From: Raphael Hertzog [EMAIL PROTECTED] Date: Thu

Bug#484549: lintian: Check that patches in debian/patches/ do not modify files in the debian directory

Hi, On Wed, 04 Jun 2008, Joey Hess wrote: Raphael Hertzog wrote: This is always wrong as the files in the debian directory are provided by Debian. Unless they're provided by upstream... Even in that case, the changes should end up in the .diff.gz and not really in a patch in debian

Bug#484549: lintian: Check that patches in debian/patches/ do not modify files in the debian directory

Package: lintian Version: 1.23.49 Severity: wishlist Usertags: 3.0-quilt-by-default During my tests on the Debian archive, I have found several cases where (quilt) patches in debian/patches/ do modify other files within the debian sub-directory. This is always wrong as the files in the debian

Bug#483384: lintian: False positive on native-package-with-dash-version with 3.0 (quilt) source packages

Package: lintian Version: 1.23.49 Severity: normal If you generate a 3.0 (quilt) source package with $ dpkg-source --format=3.0 (quilt) -b mypackagedir and you analyze with lintian the generated source package you'll end up with something like this: W: quilt source:

Re: Generated files and patch systems

On Sun, 25 May 2008, Mark Brown wrote: On Sun, May 25, 2008 at 01:07:56PM +0100, Neil Williams wrote: So I am running the relevant autotools at build time but I still get the warning. If you run autotools at build time you should also ensure that the changes which autotools makes are

Bug#471853: lintian: False positive in udeb: maintainer-script-lacks-debhelper-token

debian/control Source: guest-installer Section: debian-installer Priority: standard Maintainer: Jeremy Bobbio [EMAIL PROTECTED] Uploaders: Raphael Hertzog [EMAIL PROTECTED] Build-Depends: debhelper Standards-Version: 3.7.3 Package: guest-installer Architecture: all Depends: ${misc:Depends}, apt

Bug#409099: lintian: debian/control::Depends check for missing commas

On Tue, 30 Jan 2007, Russ Allbery wrote: An example: debian/control Depends: ${shlibs:Depends} ${misc:Depends} SUGGESTION If possible, detect the missing commas in debain/control fields like Build-Depends and Depends. That is: * After a word or ending paren, a comma

Bug#468927: lintian: Should not rely on dpkg-source's output ...

Package: lintian Version: 1.23.45 Severity: important The dpkg team is heavily refactoring dpkg-source and while using the new version on my system, I discovered that it broke lintian because the output messages got changed (and also -q will quiet all messages, not only warnings). The problem is

Bug#468927: lintian: Should not rely on dpkg-source's output

Note that /usr/share/lintian/checks/cruft relies on unpacked being a symlink so you'll have to take care of that too... Because I just did the suggested change and got this: Use of uninitialized value in string at /usr/share/lintian/checks/cruft line 131. Can't stat : Aucun fichier ou répertoire

Bug#466979: lintian: Learn new fields Checksums-* in .dsc and .changes

Package: lintian Version: 1.23.45 Severity: normal The upcoming dpkg will add new fields in the .dsc and in the .changes files: you should accept/recognize by default the fields Checksums-Sha1, Checksums-Sha256 and Checksums-Md5 (though the latter is auto-removed for now as it would be a

Bug#459787: lintian doesn't accept origin and bugs field in binary packages

Hi, On Sat, 12 Jan 2008, Russ Allbery wrote: I should also say that those should also be fixed IMO: I: dpkg source: non-standard-arch-in-source-relation kfreebsd-i386 [build-depends: libselinux1-dev (= 1.28-4) [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64]] I: dpkg source:

Bug#459787: lintian doesn't accept origin and bugs field in binary packages

Package: lintian Version: 1.23.42 Severity: normal I always get: I: dpkg-dev: unknown-field-in-control bugs I: dpkg-dev: unknown-field-in-control origin Since dpkg-gencontrol propagates Origin and Bugs fields to binary packages, lintian should accept them in binary packages. Thus you need to

Bug#457067: Patch for symbols support

. Closes: #457067 + + -- Raphael Hertzog [EMAIL PROTECTED] Mon, 24 Dec 2007 10:31:34 +0100 + lintian (1.23.41) unstable; urgency=low The it would be lovely if there were an actual desktop file standard

Re: Coordinate time for the lintian URL updates

On Thu, 20 Dec 2007, Russ Allbery wrote: lintian has migrated to testing, so I'm now ready to update lintian.d.o. An update will mean a full-archive run, which takes a little more than a day, after which the old maintainer URLs will be no more and the new format with the e-mail address must be

Bug#457067: lintian: Check symbols files and warn about usage of Debian revisions

Package: lintian Version: 1.23.41 Severity: wishlist Maintainers are now starting to use symbols files, but maintaining symbols files needs quite some work and it's easy to forget doing it. It would be good if lintian could help remind maintainers that they have to update their symbols files. But

Bug#446768: lintian: Bug in pred_implies in lib/Dep.pm

Hi, On Mon, 15 Oct 2007, Russ Allbery wrote: Raphael Hertzog [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.34 Severity: normal I worked on creating a Dpkg::Deps module for dpkg and used lib/Dep.pm as inspiration for some parts. I think I discovered some errors

Bug#446768: lintian: Bug in pred_implies in lib/Dep.pm

Package: lintian Version: 1.23.34 Severity: normal I worked on creating a Dpkg::Deps module for dpkg and used lib/Dep.pm as inspiration for some parts. I think I discovered some errors in that code while writing Dpkg::Deps. If you want to compare with my (object-oriented version of the) code,

Bug#375318: lintian: New python related checks

Package: lintian Version: 1.23.21 Severity: wishlist With the latest changes in python-related packaging, some comme patterns of error are starting to emerge... so let's check them with lintian. 1/ If you detect dh_pysupport or dh_pycentral, you should have a corresponding python-support or

Re: Uploads

(moving to lintian-maint) On Fri, 23 Jun 2006, Russ Allbery wrote: Raphael Hertzog [EMAIL PROTECTED] writes: FWIW, packages using CDBS and the python-distutils class and Build-Depending on python-dev have a similar warning... and yet they need python-dev for the clean target. Yeah

Bug#372748: Deprecating /usr/lib/site-python in python policy

On Sun, 11 Jun 2006, Thomas Viehmann wrote: --- lintian-1.23.21/checks/files.desc 2006-05-04 05:37:21.0 +0200 +++ lintian-1.23.21.tv0/checks/files.desc 2006-06-11 18:36:34.0 +0200 @@ -360,6 +360,12 @@ Info: Debian packages should not install into tt/opt/tt, because it

Re: Bug#109642: debhelper: Simplify inclusion of lintian overrides

On Sat, 21 Jan 2006, Russ Allbery wrote: But IMHO, debian/package.lintian-overrides should automatically be installed in /usr/share/lintian/overrides/package by one of the dh_* script (maybe dh_lintian could be folded into a generic dh_ script?). Please make it just package.lintian; the

Bug#348978: Lintian shouldn't warn about hardlinks if they are all inside /usr/share/package or /usr/lib/package

Package: lintian Version: 1.23.14 Severity: normal While working on a new version of sql-ledger we decided to use hardlinks (and not symlinks) between several files inside /usr/lib/sql-ledger/. The upstream author prefers hardlinks over symlinks because they are better handled by suexec. And