On 8/29/2019 8:32 PM, Andrej Shadura wrote: >> So `3.0 (native)' is not strictly better than 1.0. dpkg-source >> refuses to work in the situation where I am saying (and you seem to be >> agreeing) that it shouldn't even print a warning ... > > I have to disagree with you but I consider this strictly an > improvement. Allowing native packages with non-native versions > significantly increases complexity of code handling Debian source > packages. Not even all Debian tools support this case; arguably it > should not be supported at all as often leads to malformed packages > being uploaded to the archive.
While this may be true on some level, it is also important to be able to build packages from checked-out source trees (say, git repositories) without an original source present. For instance at work we check in whole Debian packages as-is (including their non-native version) to fork and then modify them. Changing the versioning scheme is pretty disruptive there. For people unfamiliar to Debian the diff is already represented in the VCS and there is no technical need to have this conveyed in the intermediate source package representation that is only needed to feed the build to the build system. Of course one workaround is to always build from the build tree and to always specify -b/-B and never build a source package at all. Unfortunately the various defaults in Debian's toolchain don't make that as easy as it should be. Some can be addressed through wrapper scripts, but then it's odd to anyone familiar with Debian. Obviously I'm not bound to that format being "3.0 (native)" but some "3.0 (dumb)" that just tars up the whole tree without caring about the version scheme would then be nice to have as a replacement. ;-) Kind regards Philipp Kern