Hello, On Tue 27 Aug 2024 at 09:54am +02, Niels Thykier wrote:
> # Your views on this ...? > > Thanks for reading through this and I hope you can help me with the following: > > 1. Is this problematic for `dgit` to support? > 2. Assuming it is problematic, where can we meet to have it palatable for > `dgit` while still achieving the principle goal that I want to solve? > > a. The "no generated artifacts in git" is one I feel strongly for. While I > assume it would trivially resolve any concerns from the `dgit` side, I am > hoping we can come to a better solution without that one. Like, what would > it take for `dgit` to support this without waiving that constraint? > > b. The "debian/control must be stable" (FTP-master auto-reject) constraint > is not in my control to change and does not seem feasible to change > either, since the consequences would be unclear for the archive at large. Thanks for working on this. We're certainly interested in packaging UX improvements -- that's much of the point of tag2upload. My first thought is that dgit already has the notion of the maintainer view of a package vs. the dgit view of the package. The former is whatever the maintainer has checked out while preparing their uploads. The latter is what you get with 'dgit clone'. So we could have the maintainer view contain the human-editable file and the generated debian/control would appear in the dgit view. The dgit view is meant to match the archive. I.e., it's got exactly the same contents as the source package. So we would want debian/control committed to it. Is that the sort of committing-of-generated-artifacts you object to? Or is it okay if the maintainer never sees it? -- Sean Whitton
signature.asc
Description: PGP signature
