I wonder if [...] we no longer want to accept some packaging practices, such as:
- debhelper compat level << 9
- source format 1.0 with direct changes in .diff.gz (no patch system)
- no support for build-arch and build-indep
I wonder if we should use the start of the next release cycle to decide
that we no longer want to accept some packaging practices, such as:
- debhelper compat level << 9
- source format 1.0 with direct changes in .diff.gz (no patch system)
- no support for build-arch and build-indep
- no support for build-arch and build-indepThat seems fine, but I'm not sure I'm knowledgeable enough to say for certain. I assume that these Just Work if I'm using modern debhelper?
I just updated Debian Trends: https://trends.debian.net/
I wonder if we should use the start of the next release cycle to decide
that we no longer want to accept some packaging practices, such as:
- debhelper compat level << 9
- source format 1.0 with direct changes in .diff.gz (no patch system)
- no support for build-arch and build-indep
What's left then? Only packages that don't patch the upstream sources at- source format 1.0 with direct changes in .diff.gz (no patch system)
Also dpatch. And also 1.0+quilt (ugh). !
On Thu, Apr 08, 2021 at 09:06:46AM +0200, Mattia Rizzolo wrote:
- source format 1.0 with direct changes in .diff.gz (no patch system)
Also dpatch. And also 1.0+quilt (ugh). !What's left then? Only packages that don't patch the upstream sources at
all?
- source format 1.0 with direct changes in .diff.gz (no patch system)
On Wed, Apr 07, 2021 at 02:03:47PM +0200, Lucas Nussbaum wrote:
I just updated Debian Trends: https://trends.debian.net/
Thank you.
I noted that the dates in the "smells" sections are still old. Could
you perhaps refresh those data as well, so that we have a better idea if things today are even more "smelly"? :)
I wonder if we should use the start of the next release cycle to decide that we no longer want to accept some packaging practices, such as:
- debhelper compat level << 9
I think it would be excessive to say "no longer want to accept" this.
And, honestly, I'd leave this alone. old compat level are going away by themselves without further pushing, plus Niels is also being somewhat proactive to deprecate the very old ones.
- no support for build-arch and build-indep
Isn't this already a rc bug for a while? ISTR dpkg is basically
refusing to build them now, and it has been a Policy MUST for years.
They should already have an open bug, perhaps you could double check
this part. Or maybe I don't understand what you are talking about.
- source format 1.0 with direct changes in .diff.gz (no patch system)
On Wed, Apr 07, 2021 at 02:03:47PM +0200, Lucas Nussbaum wrote:
I just updated Debian Trends: https://trends.debian.net/
Thank you.
I noted that the dates in the "smells" sections are still old. Could
you perhaps refresh those data as well, so that we have a better idea if things today are even more "smelly"? :)
I just updated Debian Trends: https://trends.debian.net/
Hi Lucas,
On Wed, Apr 07, 2021 at 02:03:47PM +0200, Lucas Nussbaum wrote:
I just updated Debian Trends: https://trends.debian.net/
Thanks a lot for Debian Trends. I have checked the code smells[1] for
I think this is a false positive:
probcons (U) does not use the machine-readable copyright format. (source version: 1.12-13)
since this version has a DEP5 copyright. Am I missing something?
Trends is just based on what lintian reports, and in that case, lintian thinks that's the case, see https://lintian.debian.net/sources/probcons
It looks like this package ships both debian/copyright and debian/probcons.copyright. While debian/copyright is DEP5-compliant, debian/probcons.copyright isn't because of the first two lines: https://sources.debian.org/src/probcons/1.12-13/debian/probcons.copyright/
[ M-F-T set to -qa@ ]
Hi,
I just updated Debian Trends: https://trends.debian.net/
I wonder if we should use the start of the next release cycle to decide
that we no longer want to accept some packaging practices, such as:
- debhelper compat level << 9
- source format 1.0 with direct changes in .diff.gz (no patch system)
- no support for build-arch and build-indep
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 90:00:25 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,100 |
Messages: | 5,277,558 |