On 5 February 2014 20:08, Guillem Jover <guil...@debian.org> wrote: > Hi! > > On Wed, 2014-02-05 at 13:54:17 +0000, Ian Jackson wrote: >> Guillem writes, on the bug but not on debian-devel: >> > Part of the definition of what's and what's not a native package is >> > the version scheme, and I've never considered that a Debian specific >> > thing specified by its policy. The fact that dpkg-source has been >> > sloppy in the past for format 1.0 does not mean newer formats should >> > not behave better in that respect, and when the change was done it >> > was "pretty early" as to not have any major impact, because the >> > current state had not been dregraded. >> > >> > This change does not affect extraction in any way, so backward >> > compatibility is preserved. If a maintainer is going to rebuild the >> > _source_ package, that means they have changed it, at which point they >> > might as well fix the bogus version. There's also no connection >> > whatsoever between the source and binary versions, so you can still use >> > stuff like pkg-source_0 with pkg-binary1_2.0-1 and pkg-binary2_1:4.0-10 >> > produced from the same source package, for example. >> > >> > Given the above, I don't see any reason at all to support this, and >> > I'm thus marking this report as wontfix, and will be closing in a bit. > >> Guillem, please reconsider. > > Sorry, I should have added here my usual note about being open to > reconsideration *if* convincing arguments are put forward. But I > was pretty much unimpressed with the way this had been brought up. > Way more so now with the threats of TC force, but I guess that's > the new Debian-way…
?! If you interpreted any of my emails as threats, I'm deeply sorry and in no way, I meant it this way. > >> Firstly, as people have illustrated, there are situations where a >> native format package with a Debian revision is a useful thing to >> have. > > What I get from that thread and previous ones is that our tools might > be suboptimal, simply suck or might make things difficult when it > comes to some specific workflows. In my book the way to fix that is to > improve the tools, create new ones or new formats, not to workaround > and shoehorn stuff into them (at least for the new formats, the old > one is incurable at this point). > >> Secondly, there doesn't appear to be any support in policy for this >> restriction. > > §3.2.1 > > “If punctuation is desired between the date components, remember > that hyphen (`-') cannot be used in native package versions.” > > §5.6.12 > > <upstream_version> > “If there is no <debian_revision> then hyphens are not allowed;” > > <debian_revision> > “This part of the version number specifies the version of the > Debian package based on the upstream version.” > … > “It is optional; if it isn't present then the <upstream_version> > may not contain a hyphen. This format represents the case where > a piece of software was written specifically to be a Debian > package, where the Debian package source must always be identical > to the pristine source and therefore no revision indication is > required.” > This is how Debian Policy defines version numbers for the Debian Project and the Debian Archive. This is not always the case for derivatives, ISV developers, or others using dpkg toolchain. My particular use case falls outside of Debian Archive / Debian Policy. Thus i'm asking to consider backwards compatibility, in a wider context. I agree that for Debian Archive and Debian Policy it is probably the right enforcmement. It's on a far lower level, than I'd expect it to be. Hence I did not propose the revert, and only proposed an optional feature flag to enable this quirky behaviour to allow, specifically, build a 3.0 (native) package with a non-native version number. <snip all the claims, which are not those that i raised and citations of debian policy which do not apply, in the context outside of Debian Developers targetting things for the Debian Archive proper> >> As you can see from debian-devel, there is a clear consensus that this >> change should be reverted. > > Sorry, but I don't see a clear consensus there. I see some people that > say this should be reverted, some that say the proposed usages are > bogus anyway, and then some confused messages about what this affects > or not. For example, what does ikiwiki (a native package with a native > version) has to do with anything? > > Can we all please back track a bit. A particular use-case I have is that, at times, there is a need to build a stand-alone src+binary packages with a strict one-to-one mapping to the src+debs already in the official archive. Especially when this strict matching source package, actually contains non-reproducible / non-free / prebuild binaries exactly against the free matching src+debs in the official archive. e.g. linux 3.13.0-6 source package, which is uploaded into the archive, built on the autobuilders. Later it is fetched, taken offline for secure-boot signing, the detached signatures stripped and assembled into a linux-signed 3.13.0-6 source package which only contains the detached signatures. At build-time of linux-signed package, it can then depend on stricly self-package version string to reattach secure-boot signature in the archive or similarly assembly singed kernel image on the client machine. In a similar fashion, i expect ISV vendors to potentially ship prebuild binaries/plugins/extension/etc in the version string matching source+deb packages in the official archives. 1.0 is a capable format that allows for this, similarly 3.0 (native) is a better one (default VCS ignore + better compression algorithms) to support this typo of atypical interaction. The 3.0 (native) is no longer possible to be build with a version string which "is_native() == true" after the fix for bug #700177 landed in 1.17.0. I agree that bug #700177 is valid, and Debian should not by default allow such misformated packages to be generated. Further I agree with Guilliem that there is no requirement, nor wide-spread use for such miss-combination (on Debian Policy terms) in the Debian Archive. And our tools should not do stupid things, or allow for stupid things to happen. E.g. like the systemd 204 upload which even with all the git-* package helper-foo and pristine-tar intentions got uploaded into the Debian Archive with an auto-generated tarball by dpkg-source. Such sloppiness is something that dpkg-source is ought to catch, and hard-fail the source package assembly. Therefore I fully agree with Guilliem's reasoning here. However, the use case of intentional matching version string to the other src+bin package from a third-party/non-free or due to signing, is in my opinion useful to those who use dpkg-source for something else then "package yet another package for the Debian Archive" and exactly to give control as to what is intentionally generated I proposed an "opt-out of hard-failure" flag --force-native to support building "3.0 (native) package with a non-native version string". I did not propose a matching flag to allow building "3.0 (quilt) package with a native version string" as i think it's silly and is much better support by e.g. "dh --with quilt" inside the native package. From a purity stand-point, we should be able to support patch queue per tarball (be it native, upstream, or tarball component in multi-tarball setup) in practice only a handful of packages reasonably need such complexities (e.g. the well-cited glibc, gcc and etc patching machineries). I believe that adding "--force-native" option flag is the universally minimal maintenance cost to support above use-case, and is on the border-line sane as at least it establishes a clear "version-string" based audit trail. My other option is to revert those set of packages to use 1.0 with worse compression rates, and "monkey-patch" / copy&paste 3.0 based ignore patterns to prevent accidental inclusion of VCS files. That would, i hope, preserve buildability of those packages with any dpkg-source. But that is increased maintainance cost, and worse performance / developer expectations - as majority of packages these days are capable of 3.0 compression algorithms and most people are used to the default ignore patters of the 3.0 based formats. I'm unconvinced about "daily snapshots" etc. arguments, as they will break if you happen to have a stale .orig.tar or dir or unclean build. You still need to manually track and increment the version number e.g. 20140206.1, 20140206.2 etc. And no, you can't just suffix a git commit id as those are not linearly incremental within a given day. Also i've seen similar silliness where commits were merged from the past, with old dates, and thus "new" src and binary packages got uploaded with a datebased version number months older than previous upload. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
