Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
Adrian Bunk writes: ... >> "The source" is what you get after steps 1 and 2. > > Why is "The source" what you get after dpkg applied patches, > but before debian/rules applied patches? I agree with Sean's point about it being a matter of definition relating to when we invoke debian/rules, but for an alternative justification one might look at this: For the Debian Maintainer, what is the preferred form of modification? It could be the source before the patches are applied (especially if they're working on a patch to be sent upstream), but really, chances are that it's actually the state of the source after the Debian patches are applied. It is almost certainly _not_ the state that source might get transformed into at some point during the build process. It is also almost certainly not the alternative version of the source that results from applying a patch series that only gets applied if they unpack the source on a different vendor's OS. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
On Sun, Aug 19, 2018 at 12:11:01PM -0700, Sean Whitton wrote: >... > On Sun 19 Aug 2018 at 09:51PM +0300, Adrian Bunk wrote: >... > > For a user it doesn't make a difference which tool applies the patches. > > In my mind, it does; it matters whether or not it is part of the package > build. That's just my expectation of what reasonable users will think. > > We're discussing what users will reasonably expect. If you and I have > different intuitions about the expectations that reasonable users will > form, we're going to have to agree to disagree. >... The user sees that the sources get unpacked, and that patches get applied. You are saying that the reasonable user will expect that these patched sources might not be the sources that will get built, and that a reasonable user will expect that additional patches might get applied during the build. Yes, we have to agree to disagree on that. > > Note that you were also arguing based on a different source > > definition: > > > > On Mon, Jul 23, 2018 at 09:22:17AM +0800, Sean Whitton wrote: > >> For example, someone might want to use a Debian system to investigate a > >> bug on an Ubuntu system. They might begin by downloading some source > >> packages from the Ubuntu mirrors. Since they obtained them from Ubuntu, > >> they will form the reasonable expectation that unpacking these source > >> packages will get them the code running on the Ubuntu system they are > >> debugging. > > > > This would be useful for debugging problems. > > > > But it is important to understand that in the general case there will > > always be cases where the code running on your system will depend on > > the architecture of your system - after applying patches the sources > > might be architecture-specific. > > Unless I'm missing something, that can only be true when the application > of patches to which you refer occurs during the package build. dpkg-source -x --vendor=Ubuntu --arch=arm64 hello_2.10-1.dsc --vendor should be implementable today based on vendor-specific patch series. --arch would require similar support for arch-specific patch series. I am not saying that a complete solution would be easy to implement, or that this might happen anytime soon. But the long-term goal should be to abolish patching during the package build, by bringing more conditional patching functionality to dpkg. This will allow packages to move away from their own custom patching systems. And it will give the user the sources that will actually get built. > Sean Whitton cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
Hello Adrian, On Sun 19 Aug 2018 at 09:51PM +0300, Adrian Bunk wrote: > Why is "The source" what you get after dpkg applied patches, > but before debian/rules applied patches? Because we define the package build as something that starts when you invoke the debian/rules script. > For a user it doesn't make a difference which tool applies the patches. In my mind, it does; it matters whether or not it is part of the package build. That's just my expectation of what reasonable users will think. We're discussing what users will reasonably expect. If you and I have different intuitions about the expectations that reasonable users will form, we're going to have to agree to disagree. Neither of us is in a position to conduct field research on this question (afaik!). > Note that you were also arguing based on a different source > definition: > > On Mon, Jul 23, 2018 at 09:22:17AM +0800, Sean Whitton wrote: >> For example, someone might want to use a Debian system to investigate a >> bug on an Ubuntu system. They might begin by downloading some source >> packages from the Ubuntu mirrors. Since they obtained them from Ubuntu, >> they will form the reasonable expectation that unpacking these source >> packages will get them the code running on the Ubuntu system they are >> debugging. > > This would be useful for debugging problems. > > But it is important to understand that in the general case there will > always be cases where the code running on your system will depend on > the architecture of your system - after applying patches the sources > might be architecture-specific. Unless I'm missing something, that can only be true when the application of patches to which you refer occurs during the package build. -- Sean Whitton signature.asc Description: PGP signature
