Bug#998282: Please make Section a required field for the source paragraph in d/control
Hi David, On Thu, Nov 4, 2021 at 7:14 AM David Bremner wrote: > > do you have some numbers According to Lintian [1] all sources among the 33,721 sources in unstable and experimental—except perhaps the ones listed below—have a Section field in the source stanza of d/control. [2] You can see for yourself by querying our JSON interface [3] with this command: wget -O no-source-section.hints 'https://lintian.debian.net/query/contexts?tag=no-source-section' It returns an empty array: [] The following sources were not checked (for resource reasons): - firefox - firefox-esr - linux - llvm-toolchain-9 - llvm-toolchain-10 - llvm-toolchain-11 - llvm-toolchain-snapshot - nvidia-cuda-toolkit - thunderbird I believe the tag functions properly because there is a unit test for it. [4] [5] Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Debian/Control/Field/Section.pm [2] https://lintian.debian.org/tags/no-source-section [3] https://lintian.debian.org/query [4] https://salsa.debian.org/lintian/lintian/-/blob/master/t/recipes/checks/debian/control/field/section/no-section-in-source-stanza/build-spec/debian/control.in [5] https://salsa.debian.org/lintian/lintian/-/blob/master/t/recipes/checks/debian/control/field/section/no-section-in-source-stanza/eval/hints
Bug#998282: Please make Section a required field for the source paragraph in d/control
Hi David, On Thu, Nov 4, 2021 at 7:14 AM David Bremner wrote: > > I think Debian would be better off if > we eliminated sections Without sections my request would go away, but that's as much of a side as I will take. > do you have some numbers Thank you for that idea! I added a Lintian classification tag for it [1] and will answer that question shortly. Kind regards Felix Lechner P.S. I would be happy to add additional tags for statistics if they are helpful to your cause. [1] https://salsa.debian.org/lintian/lintian/-/commit/bc48c6e2114c1cf9ca143db3ad9b6068ddca791d
Bug#998282: Please make Section a required field for the source paragraph in d/control
Package: debian-policy Hi, The installable stanzas in d/control (called "binary package paragraphs" in policy) inherit the Section field from the source paragraph. There is no reason to provide inheritance the other way around. Also, sources may not build successfully on all architectures. People do not often use Debian's sources directly, but we distribute them just like installation packages. The Section field in the source paragraph (called "general paragraph" in policy) reveals important clues about the DFSG-classification of the sources. It should be required. Policy section 5.2 presently shows the field as merely recommended. Thanks! Kind regards Felix Lechner
Bug#968154: Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way
Hi, On Fri, Dec 4, 2020 at 7:24 PM gregor herrmann wrote: > > Could we maybe wait for a fix for #968154 in debian-policy? I'm not sure what the policy team's intentions are, but Lintian's Data module no longer provides the policy information. [1] We now keep the data in a JSON file that is more reliably exchanged and updated. [2] As a courtesy to this package (and to the policy team) Lintian now ships an executable "/usr/share/lintian/private/latest-policy-version" that provides the latest policy information. [3] Please use that executable to obtain the information you require. As a side note, Lintian no longer ships its private modules in the public Perl path. [4] Please do not use our modules directly anymore. We would be happy to give you access to additional data via executables, if needed. Marking this bug "important" because Debian CI is failing (but separately, since I copied the policy bug). Thanks! Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/commit/d2f692f564ac725a0eb58a7d62abe57f66cdc753 [2] https://salsa.debian.org/lintian/lintian/-/commit/21fd3c7d1ae24bf3bb00ffbab6a0dd99acd3503c [3] https://salsa.debian.org/lintian/lintian/-/commit/d43799ae30f55e8a211281295d4508b11d022147 [4] https://bugs.debian.org/968011
Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages
Hi Sean, On Fri, Aug 13, 2021 at 11:08 AM Sean Whitton wrote: > > It is useful metadata about the state of a package for when NMUers or > those outside of Debian want to work with it. How do you know that people actually bring their packages up to the latest policy revision before they update the Standards-Version field? I believe people bump the Standards-Version in order to unleash the most recent Lintian tags, which is a fallacy that makes the field unreliable, and probably superfluous. Kind regards Felix Lechner
Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages
Hi, On Fri, Aug 13, 2021 at 9:12 AM Bill Allombert wrote: > > Then I would suggest that a new lintian category is designed to catter > for such usage, so that tools might chose not to display such warnings > as they do with 'P: pedantic' currently. I am not sure that helps. The tag 'outdated-standards-version' does not offer solutions to an obscure but undisputed deficiency. It states: "You are too slow." In other words, the tag does not suffer from the pedantism of a zealous prosecutor but rather from the cruelty of a taskmaster. It is not appropriate at any level. Kind regards Felix Lechner
Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages
Hi, On Fri, Aug 13, 2021 at 12:57 AM Bill Allombert wrote: > > Is there some new external factor that make any unaddressed lintian > warnings problematic ? That may go beyond the scope of the present discussion, but yes: First, Lintian packaging hints are always viewed as imperfections; contributors strive to make their packages "Lintian-clean". Second, we now offer performance measures that will eventually help to improve or drop tags people find "noisy," i.e. those with a high rate of false positives. Here is an example for a tag that, being 95% accurate, works well. [1] The tag 'outdated-standards-version' operates completely outside of that paradigm. It always is, and forever will be, noisy. I see myself as an advocate for the folks who like Lintian but are annoyed by it. More often than not, they are right. Kind regards Felix Lechner [1] https://lintian.debian.org/tags/spelling-error-in-binary
Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages
Hi Sean, On Thu, Aug 12, 2021 at 3:37 PM Sean Whitton wrote: > > I believe that we failed to consider udebs when we made the change which > made S-V mandatory. I propose we remove the requirement for S-V in > udebs and source packages producing only udebs, until and unless someone > provides a positive argument why S-V ought to be mandatory in these > cases too. Would you please point to the argument for why d-i micro debs are exempt from policy, or from a documented Standards-Version, or both? In addition, it would be helpful to have a short explanation from the Policy Team as to why Standards-Version is now required. This primary but brief bug report [1] cited a high prevalence in the archive, but that was then not a convincing argument, and is even less so now. Many contributors at the time, myself included, did not realize that the field was optional. [2] They probably put their faith in Lintian, which has warned about the field in one way or another since 5 April 2004—for more than fourteen years before the field finally became mandatory. Our contributors included the Standards-Version field through punitive conditioning, and not because they loved it. The most curious part? The two bug reports that started it all [3][4] (and have since been merged) were actually about making Lintian—and by extension Policy—"less pedantic" yet somehow we ended up with the opposite result. How did that happen, please? I later dropped the tag 'ancient-standards-version' from Lintian for unrelated technical reasons [5] Holger supported it (but did not instigate it) and I was unaware of his role in the 2018 filings. The relevant emails from debian-devel are too philosophical about Lintian's role. [6] They have little bearing on the issue now before us. There is, as a side note, another common misconception that Lintian somehow uses the field to calibrate its output; it does no such thing. Finally, please allow me to add some powerful statistics to the record. The tag 'out-of-date-standards-version' currently occurs in 10,813 source packages in the archive (out of about 33,000). [7] It is an incident ratio of 33%. That number will never budge, unless someone authorizes the Janitor to do what most maintainers do, i.e. update the field without great ado. There are no overrides, which should probably not be legal anyway but also make no sense. Our group effort to update the field is a hopeless and demotivating climb. Thank you! Kind regards Felix Lechner [1] https://bugs.debian.org/886258 [2] Based on IRC discussions I witnessed at the time. [3] https://bugs.debian.org/886219 [4] https://bugs.debian.org/886210 [5] https://salsa.debian.org/lintian/lintian/-/commit/53ead395a217a8a7969f7f96e3882d2da402c96d [6] https://lists.debian.org/debian-policy/2018/01/msg7.html [7] https://lintian.debian.org/tags/out-of-date-standards-version
Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages
Hi Sam, On Tue, Jul 27, 2021 at 7:42 AM Sam Hartman wrote: > > I'd need to know more ... in order to have an opinion on > whether there should be an obligation to comply with these aspects of > policy. Thank you for your line of thinking. I totally agree with you. > 1) I realize i don't entirely know why udebs are udebs not debs. I would like to understand that too. From what I can tell, setting a flag in the binary DEBIAN/control file would have been superior since the formats are actually the same. (Perhaps the custom extension ensures that APT does not get confused between both kinds of installables without opening them; in that case I would have chosen a basename postfix.) > I'd say that there are significant chunks of policy it would be a great > idea for d-i packages to comply with. Are source packages building d-i micro debs exempt from policy? Is that even possible? Thank you! Kind regards Felix Lechner
Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages
Hi, On Mon, Jul 26, 2021 at 7:08 PM Cyril Brulebois wrote: > > It doesn't have to > follow the letter of Policy, does it? The Lintian maintainers are happy to participate in a discussion, but they do not implement their personal policy stances in defiance of the project's authoritative documentation. As noted, the use of Standard-Version is, in my view, a packaging error everywhere—and not just in udebs. To that extent we are allies; otherwise Lintian is not the right place for you (or I) to address concerns about that pestering and unnecessary field. Thanks for copying -policy! Kind regards, Felix Lechner
Bug#953629: Bug#953554: Please permit Debian revisions with 1.0 native packages [and 1 more messages]
[This is the policy bug.] Hi, On Mon, Jun 15, 2020 at 5:18 PM Sean Whitton wrote: > > the relevant sentence of Policy ... was intended to be > informative, not normative. Just a brief post scriptum: I had to disable a test in Lintian due to new restrictions on version strings in Dpkg. The commit message has more documentation: https://salsa.debian.org/lintian/lintian/-/commit/5f0333ebc6e3ba144717eca1ef0bddfd39413df0 Kind regards Felix Lechner
Bug#963524: dpkg: source-only *.changes files lack two mandatory fields
Hi Chris, On Tue, Jun 23, 2020 at 3:58 PM Chris Lamb wrote: > > to me this is a simple oversight in the Debian Policy That's exactly what I wrote in the initial filing. Kind regards Felix
Bug#953629: Bug#953554: Please permit Debian revisions with 1.0 native packages [and 1 more messages]
Hi Sean, On Mon, Jun 15, 2020 at 5:18 PM Sean Whitton wrote: > > As > discussion is ongoing in the context of Lintian, that seems premature, > however. The Lintian discussion was merged into a bug Guillem had filed to further enshrine the division between native and non-native packages Bug#944155 was about reminding maintainers to use a hyphen, or not. Based on your note, however, Lintian will stop warning about such version mismatches. Perhaps it will gradually pave the way for a constructive policy debate. Thanks! > So I think we can close the clone of this bug against Policy for now. Totally agree, for now. Kind regards Felix Lechner
Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages
Hi, On Fri, Jun 12, 2020 at 3:30 AM Ian Jackson wrote: > > As for `3.0 (native)', it has one serious disadvantage: dpkg-source > has been programmed to reject version numbers with a Debian revision. > If that restriction were relaxed, `3.0 (native)' would be a strictly > superior drop-in replacement for 1.0-native and I doubt anyone would > have any objection to phasingt 1.0-native out completely. What a winning trade! The restriction should be lifted right away. Kind regards Felix Lechner
Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages
Hi, As a Lintian maintainer, I would like to express support for Ian's effort to remove restrictions on Debian version strings. Unlike Ian, however, I also believe all packages should be converted to format 3.0. A package's 'nativeness' is then declared explicitly, and does not have to be inferred from the version string. Lintian still does the latter for installation packages (aka 'binary' packages) because the expected changelog locations differ (and tags are issued accordingly). In my view, nativeness should only matter for source packages. The provenance of an installation package should not matter. I wrote this message because the Lintian bug that is blocked by this one will be triaged in another way. Lintian supports Ian's effort to the extent that it simplifies the parsing of version strings. Kind regards Felix Lechner
Using /usr/bin/env to invoke maintainer scripts
Dear Policy Team, > Does Debian Policy prohibit the use of /usr/bin/env? Lintian flags the interpreter /usr/bin/env in maintainer scripts. Unfortunately, that appears inconsistent with the recommendations for scripts in Debian. Policy section 6.1 states that "Programs called from maintainer scripts should not normally have a path prepended to them." It says further that "any ... program that one would expect to be in the PATH, should ... be invoked without an absolute pathname." Finally, it expands on the point with "These considerations really apply to all shell scripts." Lintian does not flag /usr/bin/env in regular, i.e. non-maintainer scripts. Why is the use of the system PATH desirable in the body of a maintainer script, but not when locating the interpreter, please (the shebang). Shouldn't we encourage the use of /usr/bin/env? Or does the calling infrastructure disregard the path? Please respond to the bug. I do not subscribe to your mailing list. Thank you! Kind regards Felix Lechner
