Ansgar 🙀 <[email protected]> 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 ([email protected]) <https://www.eyrie.org/~eagle/>
