Re: Git Packaging: Native source formats
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
Reply to: