Re: Bug#737634: dpkg: is_native version checks in dpkg 3.0 Native
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…
> 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.”
> Thirdly, notwithstanding your comments, I think this change is a
> problem for backwards-compatibility. People modifying source packages
> might be doing so in a context where they don't want to, or can't
> conveniently, change the version number of the source format. They
> might also be using dpkg-source to prepare packages for a downstream
> distro who don't have the same fixed opinion about the versions.
If people are preparing stable updates, I'd expect them to do that in
a stable system, no problem here. If people are updating ancient
source packages in a modern system they will need to change way more
things anyway (due to compilers, deprecated stuff, etc). If people
are updating someone else's package (say an NMU) for a bogus native
package, they have to create an entire new source package with new
upstream tarball(s) anyway, switching the source format is a very
tiny change in comparison, and this type of change is pretty common
when transitions or unrelated FTBFS bugs are involved. If the context
is completely outside of Debian, and neither the source version nor
the source format can/wants to be changed (?), that _might_ call at
most for a force option allowing bogus versions, but certainly not
for a revert. But please, see below for how big of a problem this
currently is in Debian.
And this is a bit of a tangent, but IMO changing the source format
(from native to non-native) is the correct thing to do anyway for
native packages when modified by someone else than the author,
because I find it's pretty inappropriate to release a new upstream
release on behalf of the upstream author, taking over the version
namespace and file release namespace when those changes might not
even survive, which can be confusing towards downstreams in other
distributions who might not be aware of these nuances, or those
changes might be part of a derivative, in which case taking over
those namespaces would be inappropriate too.
> Can you please explain what you think the concrete benefit is of this
> change ?
Our source packages are already pretty complicated, mixing native
packages with non-native versions (and the reverse which is even worse)
adds to the confusion, for current and new packagers, and external
people to the project (we'd have what, true-native packages,
half-native, non-native, non-native-haha-version, etc?). The
distinction in source version 1.0 was pretty flaky, as it was defined
by the presence of specific filenames. With newer source versions this
is made explicit, if then the version scheme does not match, it makes
it even worse.
Disallowing bogus versions from the root (that is dpkg), makes for
better packages in our ecosystem, even for people that do not know or
cannot be bothered to know about these distinctions. It also reduces
having to handle strange corner cases in support tools (as Bernhard
has pointed out).
Usage of native format packages (any version) for non-native upstreams
implies that for each packaging revision there's a new source tarball,
this might be passable for the 47-odd packages doing so currently
(althought some of those should be true-native), it certainly does not
scale at all in the future if applied to the whole archive (even less
so if those packages start also shipping stuff like the entire .git/
directory), regardless of the usual “disks are cheap” mantra.
It's also a disservice towards derivatives and other people using
these source packages as a base, as the changes are not clearly
separated and visible. If people think juggling source tarballs
around is antiquated and a nuisance, and the only true form of
distribution should be the DVCS-of-choice, then let's drop these
source formats, but let's not abuse them for something they are
not designed for.
My impression is that most of the cases in
<http://lintian.debian.org/tags/non-native-package-with-native-version.html>
and
<http://lintian.debian.org/tags/native-package-with-dash-version.html>
are due to either mistakes/sloppiness, not knowing things like that
date-based versions (such as 2010-09) are problematic for native
packages, ignoring the fact that source version and binary version
do not have to match at all as long as they increment monotonically
(like the default package cases), or abusing the current formats for
a different workflow.
The last two options seem to be the only ones done on purpose, the
former is a matter of using a correct native source version distinct
from the binary package ones. The latter might be a matter of
improving our tools or similar to support such workflows.
> At the moment we have numerous packages in this state and
> they don't cause any problems.
We have exactly three (3) packages in unstable that are in this
state, namely: davical, pimd, tk-brief. We had 9 when this change got
introduced, and none for the «3.0 (quilt)» with native version.
> 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?
(And a preposterous proposal, I guess I should be changing also
Dpkg::Version->is_native() to return "maybe"? :)
Thanks,
Guillem
Reply to: