Hi, On 4/8/24 05:42, Wookey wrote:
I don't mind what other people do, but I worry that conversations like this seem to take the new thing as so self-evidently better that no-one can reasonably complain about them being made a requirement. Well, we don't all think it's better, and I wouldn't enjoy seeing 'packages must be in Salsa' made a requirement, for example.
What people seem to be missing is that the Debian archive *is* a version control system.
Stacking another VCS on top of it leads to a lot of annoying artifacts, because there is no sensible metadata mapping between them -- what is metadata in Debian becomes data in git, and another metadata layer is added on top of that, and what is data in Debian must be run through a filter to make it accessible to git for efficient handling, so part of it gets converted to metadata.
The result is... not ideal, because the resulting workflow is neither a Debian nor a git workflow, but a mix that requires users to be aware of the state of two systems at the same time. Testing a package requires me to commit everything into git first, so I have to remember to squash all these commits later.
As long as there is no clear benefit, for example in a team maintained package where multiple team members regularly collaborate on pre-release states without uploading a Debian package in between, it mostly adds to my workload -- especially if no upload is made for a change, whoever does the upload will need to remember to review all of these changes. In the context of the xz debate, I'd expect this to increase, not decrease attack surface.
The web interface presented by salsa also does not have the necessary data<->metadata filters to provide an actual insight into what is really happening in the repository.
Because metadata is stored as data, building such filters would also be nontrivial. The existing gbp repositories pretty much all use a merge commit to integrate a new upstream version, but do not update debian/changelog in the same commit, so any tool analyzing this commit would see all the upstream changes for the new version as Debian specific changes against the old. Practically the only commits that are safe to analyze in this way are the tagged releases.
What would make sense would be a git based format that is designed around the requirements for package maintenance, and where internal consistency can be enforced by upload hooks -- for example by storing metadata out-of-band in a separate branch.
Simon
