I've spoken to Johannes and I have a clearer understanding of his concerns.
The main thing I was missing in my suggestion was to clearly distinguish the behavior from two use cases: 1) sbuild is called with a .dsc as input file 2) sbuild is called with an unpacked source tree as input. On case number 2, sbuild will create the .dsc (with the d/rules clean target) and feed that into the workflow used for use case #1. The people in this bug report, and I assume most people outside of it, mostly used sbuild with the second use case, but some people (and buildd itself) falls under scenario #1. The solution needs to make sure not to fiddle with the .dsc used as input, for example: it should not re-generate a .dsc when inside the chroot if the input was a .dsc already. For the second use case, Johannes would accept a solution, but he believes it's not going to be straightforward due to the way sbuild works today. For the second use case, I've mentioned the possibility of generating a temporary .dsc, feeding that into the chroot, regenerating the .dsc there, and using that one as the build artifact. Johannes said there might be issues regarding sbuild hooks used for when the .dsc is first fed into it. Those hooks could result in values from the initial .dsc to be used instead of the final .dsc. This was a bit of a convoluted proposal anyway, so what I believe it's the most clean solution is: Add logic to send the unpacked source tree straight into the chroot, generate the .dsc there and use it as the build artifact, but this should ONLY happen if the input is not a .dsc. There's a parameter which already lets users get a .dsc from the chroot as the build artifact: --source. So most of the complexity relies on implementing the "move unpacked source into the chroot" and "only behave as --source if the input was an unpacked source tree" features. Johannes, feel free to correct me if I got anything wrong based on our conversation. And if anybody reading this is interested in implementing it, please go ahead. I want to give it a try myself but I don't know when exactly I will have the time. Cheers, -- Samuel Henrique <samueloph>
