Re: Summary: Git Packaging: Native source formats
(Even though it was not clear in the initial mail, I'm assuming
this is about using native format 1.0 with non-native versions.)
On Fri, 2019-08-30 at 12:57:56 -0400, Sam Hartman wrote:
> My take away from this discussion though is that using a native package
> format even when there are upstream sources is an appropriate tool for
> maintainers to use sometimes.
I have to strongly disagree with this. We have 1.0 source packages
that currently do this, some out of error (due to the flakiness of
the format), some due to maintainer choice. Like last time this was
discussed here, I think both usages are wrong.
> I think that is a significant change over our feelings years ago.
My feeling is that repeating all this stuff over and over again is
exhausting, more so when it comes to the git workflow/packaging stuff.
> Back in the day I think there was approach a project consensus that
> using native format packages with upstreams that were native to Debian
> was basically always wrong.
It's still very much wrong. Of course if you are upstream and are
releasing native source packages, that's obviously fine. A Debian
maintainer could then either just upload them as-is, or turn them
into non-native source packages for upload.
> My reading of this discussion is that it's a tool that maintainers
> should have and it's sometimes reasonable to use that tool. People have
> done a great job of bringing up athings to think about for maintainers
> considering using that tool. I've certainly found the discussion
> educational. It's changed my thinking about when I would choose to use
> native format packages in the future.
It might be a way out maintainers feel is convenient, it does not
mean it's right. Due to at least:
- This is an aberration of the defined meaning of the terms, and
what they imply. So makes communicating things harder and
confusing.
- It breaks assumptions and consistency between version, source
format and source content, and the tools dealing with these.
- It implies releasing tarballs as if we were upstream with
additional content that upstream has never provided (which is
very different to stripping out content and then marking this
in the version).
- It makes using Debian source tarballs by third-parties unreliable.
- It makes downloading just the packaging bits more costly.
- It makes making sure what truly got modified more costly, because
you cannot know easily whether a patch got applied in the actual
tarball.
I've never seen an actual good reason for this practice, except for
the “doing it right is a bit more work”, TBH.
If the maintainer wants to generate a tarball out of git, they can do
that right now with «git archive» and using a version based on a the
upstream version + date + commit-id, then using that as the orig.tar.
It has the same space inefficiency drawback, but at least it is correct.
I'm planning to add warnings for 1.0 formats when using a version that
does not match the type of tarball found. Ideally 1.0 formats would
error out in the same way 3.0 do, but this is impractical, and I guess
we'll just have to wait it out until 1.0 formats die off. :(
Thanks,
Guillem
Reply to: