Hi, On 5/21/24 15:54, Andrey Rakhmatullin wrote:
The Debian archive itself is a VCS, so git-maintained packaging is also a duplication, and keeping the official VCS and git synchronized is causing additional work for developers, which is why people are opposed to having it mandated.
The Debian archive itself is a *bad* and *poor* VCS. It should be obvious in which areas it's poor, and it's bad e.g. because force pushes are enabled, the history is periodically truncated (though there is no easy way to get it anyway) etc.
All of these things are *also* explicit features. We need a way to unpublish things, and mirrors only want to keep a shallow subset.
Representing the Debian archive in git would probably look like a massive amount of submodules, because that's the only way to represent state across multiple projects without extending it -- and extending is a big no-no, because then we'd lose all the forge support. Submodules cannot represent the pristine-tar branch though.
It makes sense that some people want to replace it with a good VCS, but I agree that adding a good VCS only gives us two VCSes because replacing will never happen.
There are two axes here -- "good" and "fits the use case."What I'm arguing is that git does not fit our use case, despite being good, because it is designed for something else. We can make it fit our use case by wrapping it, but then we have a choice between a thin veneer that breaks easily as people use git commands inside a source tree, when they should only be using gbp commands, or a completely opaque wrapper that loses us all the git integration from third-party tools like forges.
Because git treats packaging metadata as data, no correctness of metadata is enforced at this level. We could add this in the form of upload hooks, but then people would start complaining that they want to use the tools like they want. They would be wrong, but that is what happens with leaky abstractions.
This is the exact opposite of the mandatory-debhelper debate: requiring declarative packaging (and therefore calcifying all custom sequences into debhelper plugins) is precisely the opposite of "using git because it is familiar" -- the benefit of using the abstraction comes from denying access to the layer below and therefore hiding its complexity.
Simon