Simon Josefsson dijo [Wed, Feb 11, 2026 at 01:59:10PM +0100]:
(...) All the things on the "Not supported" ways can be considered bugs elsewhere -- thus I think the title of that section could be changed to "Design limitations" or similar instead.
I agree on this. A tool should not be promoted as the only one right and modern way to interface with the archive as long as it does not address some widespread and useful use cases.
(... several points I completely agree with ...)"pristine-tar: With a new upstream version, tag2upload will generate a fresh orig tarball with git archive (via git-deborig). This is OK, but it may surprise some users. 1106071."This is probably the toughest nut, and is mostly a matter of opinion if pristine-tar is a good pattern and offers anything useful. I used to be a big supporter of pristine-tar, but I'm now neutral. Pristine-tar doesn't offer the strong security properties or features that I thought it did, and comes with a large storage and transfer cost.
I agree, I do not _love_ pristine-tar, but I do _use_ it. And I don't want to ditch it just to try a new tool.
Uploads to security-master. This is difficult: 862105.TBH I have no idea about this one, but I suspect the security-master upload workflow isn't particular modern.
Maybe it is not particularly modern, but it is _vital_. And as long as we have to teach newcomers to use a different tool whenever they need to do a security upload, I cannot support having The Single Sanctioned Workflow™ to be one that cannot be used. A different set of tools have to be learned by our developers to do security support.
Uploads to backports where your workflow involves throwing away the changelog entries for previous backports. I.e. if you start fresh for each version from testing you backport. If you do something like git checkout debian/bookworm-backports && git merge debian/latest and then resolve the debian/changelog merge conflict so as to preserve all entries, then it works (1109584).The special debian/changelog handling for backports has always seemed odd to me. I think having in-package changelog files are increasingly becoming an obsolete pattern, for the same reasons ChangeLog files are now less relevant.
I do believe there is important value in having a human-readable, human-oriented debian/changelog. Not all commits are of the same importance, and having a document written so that readers understand the main issues in a way that does not assume familiarity with implementation details is important IMO. Now, I know this is not an issue WRT git-debpush, it only highlights a –again, IMO– minor nuance where a bit of usual practice has to be changed.
NMUs that don't use the package maintainer's git repository, and git workflow, aren't likely to work well. Instead, use dgit, which offers a completely uniform git-based NMU workflow.Doing NMUs without pushing to maintainer's repository leads to a mess that is frustrating to clean up from (look at some NetKit packages), and the only reason why anyone would ever do that is because some maintainers protect commit access to their packaging. Which is a real problem.
...And that some maintainers do not keep their packaging in a VCS (and, particularly, in Git). Yes, this is finally seen as a problem rather than norm, but still...
DELAYED/DEFERRED uploads (1123680).I think the concept of DELAYED/DEFERRED, like NMUs, are historic ways of working which today have better methods: bug-reports, merge requests, Salsa pipelines, Debusine uploads, or mailing-list discussion.
Here, I disagree. I find DELAYED/DEFERRED a good, useful practice. It is a good way to fix a bug in an NMU if you are not sure the package maintainer is active and you don't want to keep the pending upload in the back of your head for X days until you get an answer — uploading something to be done a week from now is a good way to say, “I did the following changes and it works for me™, feel free to roll it back before it reaches the public”. I would love it if, for several of the last points, we lowered this notion of “package ownership”. I would love that Debian held a culture where the Maintainer/Uploader fields stated who is most likely to respond to issues with packaging, but where every package would be a valid upload target for all of us. But I know many people are not willing to embrace something that strong.
signature.asc
Description: PGP signature
