Hi, On 6/19/24 17:33, Aigars Mahinovs wrote:
- we need to store the actual contents in the archive, not just a reference to an online service, or the online service becomes part of the archive.
Effectively the dgit.debian.org becomes the archive or the snapshot service of the git view of the Debian source packages.
Exactly: this is not an "editorial change", but a major revision of how Debian works, and I would at least expect Policy to be updated accordingly.
People interacting with Debian on the Debian source package level can keep doing that exactly as before. But to access a deeper, git level of source you would, naturally, have to use different tools and access a different service.
Is there a requirement for maintainers to accept patches submitted via the BTS that are based on the last published source package, or can they insist on pull requests made through a website that requires the users to download a few megabytes of JavaScript? :>
- we need to distribute that on CDs and mirrors (which both have size constraints)
Do we? Already Debian source packages are in reality a separate set of DVDs (we don't even provide source on CDs anymore) and only a subset of mirrors. While having an option to have a dgit server mirrored might be nice, it does not really have to be inside the current mirror or archive structure. And it does not have to be a blocker.
If dgit becomes the archive, not being able to mirror it is a major regression.
- we need to keep and archive also the tools required for processing
Which should be trivial as long as they are packaged.
Do we impose any compatibility requirements? I.e. can we expect that dgit tools in bookworm will be able to check out any package in trixie? Do we expect trixie+1 to be able to reproduce packages released in bookworm, or can we drop compatibility code at some point?
For example, the "clinfo" packages that were shipped in jessie and in stretch and following are completely unrelated, they just have similar enough output that one could be used as a replacement for the other.
If those had been git-maintained packages, how would those have been archived? Is the dgit package namespace separate from Debian source package names?
Well, there are many ways to do that. For example have a merge commit that merges in the new upstream into the old upstream branch where the merge commit itself deletes all old files and replaces them with the new files. The Debian changelog would note the changed upstream and move on as normal.
This gets really ugly really fast though: the current package would still ship the old history for no particular reason, and this schema breaks when one upstream repo uses sha1 and the other uses sha256.
I still think there are fundamental design flaws with the data representation that break several use cases, yet there is an expectation that this will become universally usable.
I think this incremental change will increment us towards some local optimum that we will a hard time getting out of.
Simon
