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
