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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140205200803.ga21...@gaara.hadrons.org
