Processed: unblock 953554 with 953629
Processing commands for cont...@bugs.debian.org: > unblock 953554 with 953629 Bug #953554 [lintian] lintian: Restore format-specific changelog tags as warnings Bug #944155 [lintian] lintian: Version format vs source format mismatch tags disappeared 953554 was blocked by: 953629 953554 was not blocking any bugs. Removed blocking bug(s) of 953554: 953629 944155 was blocked by: 953629 944155 was not blocking any bugs. Removed blocking bug(s) of 944155: 953629 > thanks Stopping processing here. Please contact me if you need assistance. -- 944155: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944155 953554: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953554 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#953554: Please permit Debian revisions with 1.0 native packages
Processing control commands: > retitle -1 lintian: Restore format-specific changelog tags as warnings Bug #953554 [lintian] Please permit Debian revisions with 1.0 native packages Changed Bug title to 'lintian: Restore format-specific changelog tags as warnings' from 'Please permit Debian revisions with 1.0 native packages'. > forcemerge -1 944155 Bug #953554 [lintian] lintian: Restore format-specific changelog tags as warnings Bug #953554 [lintian] lintian: Restore format-specific changelog tags as warnings Marked as found in versions lintian/2.32.0. Bug #944155 [lintian] lintian: Version format vs source format mismatch tags disappeared 944155 was not blocked by any bugs. 944155 was not blocking any bugs. Added blocking bug(s) of 944155: 953629 Marked as found in versions lintian/2.55.0. Merged 944155 953554 -- 944155: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944155 953554: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953554 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages
Hi, Sam Hartman wrote: > I think there are at least two cases where this issue comes up and is > important, and where using a debian revision without separate upstream > tarballs is the right approach: > > 1) small packages currently maintained by the upstream maintainer where > debian revision is incremented for packaging only changes and upstream > revision is incremented for upstream versions > > and > > 2) Cases typically outside the Debian archive where a git tree is being > built as a Debian package especially as part of a CI system and where > the effort of tracking upstream tarballs is undesired. > > 2) is more of an issue for lintian than it is for debian-policy. I don't have any strong opinions about this, but I got the impression that Ian's motivation is a different case 3): | Most packages are maintained in git nowadays. It is usual to have a | separate git branch for Debian and upstream work. In such a situation | it makes perfect sense to have an upstream version number which | corresponds to an upstream tag. For packages with a very small (or | zero) Debian delta to the upstream files, it makes sense to maintain | these git branches using `git merge' rather than as a stack of | patches. | | However, there are serious inherent problems with all of the | non-native source formats. There are many that can occur in git | repositories which are not representable in non-native packages. For | example, changes to symlinks. Worse, one must either choose | `3.0 (quilt)' which involves patch files within the git tree | and a great deal of complexity to manage those; or 1.0-with-diff which | has an even more restricted set of things it can represent. Regardless of what happens to the 1.0 format, shouldn't the non-native package formats be improved to handle this? The "git diff" format, which GNU patch has reasonable support for, is able to represent all of these kinds of changes, including changes to symlinks. Tooling for handling 3.0 (quilt) packages is reasonably good at generating an appropriate single-diff quilt at build time. To the extent that this doesn't work, it seems worth fixing. Thanks, Jonathan
Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages
I strongly agree with Ian in this matter. I think there are at least two cases where this issue comes up and is importand, and where using a debian revision without separate upstream tarballs is the right approach: 1) small packages currently maintained by the upstream maintainer where debian revision is incremented for packaging only changes and upstream revision is incremented for upstream versions and 2) Cases typically outside the Debian archive where a git tree is being built as a Debian package especially as part of a CI system and where the effort of tracking upstream tarballs is undesired. 2) is more of an issue for lintian than it is for debian-policy. While I feel strongly about this, and believe that I adequately explained my position years ago on debian-devel when dpkg first started rejecting packages with debian revisions and 3.0(native) format, I don't have the emotional energy for a discussion of this. The way I was treated by the dpkg maintainer back then caused me to stop working on Debian for months and seriously consider moving on to other things. I just don't have the emotional bandwidth to deal with a discussion where well-considered arguments will be ignored and/or dismissed with little consideration. So, +1 on this, but don't expect me to be able to participate much in the discussion. signature.asc Description: PGP signature
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
