Re: [RFC] General Resolution to deploy tag2upload
Ansgar 🙀 <ansgar@43-1.org> writes:
> On Wed, 2024-06-19 at 07:45 -0700, Russ Allbery wrote:
>> No, the uploader doesn't know this. Some of the files (the ones in
>> debian/patches) are synthesized from Git commits and do not exist at
>> all in the checkout of the Git tree, which will often be in
>> patches-applied form.
> Hmm, I did not think of people effectively forking the upstream project
> instead of doing only packaging.
This is a very common case in Debian, though. A lot of packages carry
upstream patches for a wide variety of reasons.
It's rather nice to use a proper VCS like Git to maintain those changes
instead of trying to use quilt as a VCS. This was true even with 1.0
source packages. It was (and I suspect still is) common to use a proper
VCS to manage all changes to the package, both in the Debian portion and
in the upstream portion, and then let the source package build system
serialize that into a diff. Nowadays the way to do that is with 3.0
(quilt) with the single-debian-patch option, which is what I used before
switching to git-debrebase.
One of the critical things that dgit, and tag2upload, provide is a nice
translation layer from a normal, ordinary Git representation to a normal,
ordinary 3.0 (quilt) package without requiring the package maintainer do
things like commit patch files to a VCS, something that a lot of us find
weird and awkward and annoying.
This was why I wrote up that long description of the git-debrebase
workflow. I suspect that some people haven't seen it before and didn't
realize that it's already possible in Debian today to use Git for Debian
packaging the way you would use it for any other project, without having
to do the branch switching of gbp pq (which is quite nice as far as it
goes but still requires doing special things to edit upstream code), and
still get nice Debian source packages rather than one giant unreadable
blob of a diff.
But even if one is happy with one giant unreadable blob of a diff, which
is what I suspect a lot of maintainers settle for, that diff isn't present
in the checked out tree and therefore isn't around to be hashed. If one
tries to generate it with whatever random tools you have sitting around,
one quickly runs into the problem that there are a lot of ways to generate
a diff between two trees that represent the same semantic change but don't
hash to the same value. This is the kind of problem that's solved in all
that dgit code that tag2upload would also use.
> People could just move to native packages if they do that: that also
> works for changes to binary files, no longer requires synthesizing
> patches and thus brings the Debian source package closer to the Git
> state. This is also easier to compare to maintainers' repository.
Sure, we could tell people to use 3.0 (native) for everything with Debian
changes to the upstream source and stop trying to use 3.0 (quilt). You're
not the first person to make that suggestion, and it has some real merit
for simplicity of representation of source packages. But that means that
we now can't share the .orig.tar.gz file between Debian package releases,
which has implications for the size of the archive. It breaks tools to
extract the patches from a 3.0 (quilt) package. And, based on previous
debian-devel discussions of exactly this, people have a lot of strong
opinions about not using 3.0 (native) when there is an upstream.
tag2upload is intended to work with what package maintainers are doing
today as much as reasonably possible, not to force them to use different
workflows and source package representations.
> (I'm a bit biased to only doing packaging, ideally unrelated to the
> upstream source code as it only describes how to use said code.)
This is a lovely situation when you can stay in it, but I have had to
introduce Debian patches even for code for which I am upstream for a wide
variety of reasons. I don't think it's realistically possible to avoid
this forever for a lot of packages.
Personally, I think the best way to think of Debian packaging is always to
think of it as a fork. You fork upstream to add the packaging rules and
build system, and you only selectively rebase your fork on newer upstreams
when you think they're ready for Debian. Sometimes it's a trivial fork
that only contains new files, and sometimes it's a more complicated fork
with other changes and you try to reconverge with upstream over time, but
it's always some sort of a fork.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: