Hello Simon, On Wed, Apr 18 2018, Simon McVittie wrote:
> Based on his work on dgit, I believe Ian considers the canonical > contents of the source package to be the patches-applied > state. Developers who agree with this point of view would say that > applying patches is part of unpacking the source package, and any > source package with vendor-specific series gets different contents > depending where it was unpacked, which seems strange - steps described > as "unpacking" are normally deterministic. > > Conversely, developers who consider the canonical contents of the > source package to be the patches-unapplied state would say that > applying patches is more like part of the process of building a binary > package (converting a source package into a binary package), which > would imply that a source package with vendor-specific series always > has the same contents (but those contents result in different vendors > building different patched source code). Thank you for this diagnosis of what's going on in this thread. I think you have put your finger on the dispute. Ian's position is supported by dpkg-source's behaviour of applying patches when a source package is extracted. On the other hand, most maintainers commit source packages to git with patches unapplied. So it is natural that people who have different intuitions about this. I suspect that the way to make progress on this bug is for dgit's tooling for downstreams to improve. Patches-applied repositories are not so easy for downstreams to manipulate, at present. There is some work going on right now on a new tool that will complement dgit and so I think we should put this bug on the backburner for the time being. Also, Mike: thanks for sharing your experience in Ubuntu. Those of us working on dgit don't contribute to any downstreams (AFAIK) so it can be a bit of a blind spot at times. -- Sean Whitton
signature.asc
Description: PGP signature
