Re: Bug#737634: dpkg: is_native version checks in dpkg 3.0 Native
On 5 February 2014 20:08, Guillem Jover <guillem@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.
Reply to: