Hello, On Sat 21 Jun 2025 at 09:22am +02, Niels Thykier wrote:
> Somehow I got the understanding that `dgit` had `maintainer view of the > package` == `dgit clone view of the package`. Your statement here sounds very > promising and like this concept would be compatible with `dgit`. I would be > very happy if I had made a misunderstanding. :) Yes, I think you did misunderstand. Currently dgit updates the dgit view from the maintainer view before it invokes the package build. It could learn to invoke your new thing to update the generated d/control as part of doing that update/conversion. To make this smooth, it would be best if it was always unambiguous just when such transformation is required. For example, the presence or absence of a particular file. That way, tag2upload gets support for your new workflow with no extra work. > My concern are only about the maintainer repo/mainline branch. If it is not > committed to the maintainers mainline branches during regular maintenance nor > require extra steps/upkeep of them during upload/release flows, then we should > be good. > Framed differently, having the files committed or requiring extra steps > would be a mental load on the maintainer I want to avoid as I see it as > diminishing the value of this proposal. > > > The maintainer will meet the generated files when merging back an NMU. That is > a possible wart of this idea, but I have not found a way around that without > breaking the FTP master requirement or my "no generated files in > (maintainer's) mainline branch" requirement. We have similar issues with merging NMUs when the dgit and maintainer views diverge. It's just the same problem. Anyway, glad to hear everything seems to be compatible :) -- Sean Whitton
signature.asc
Description: PGP signature
