Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
On Sun, Aug 19, 2018 at 10:13:56PM +0200, Philip Hands wrote: > 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? The maintainer might actually know how his self-written patching machinery works. I am doing plenty of bugfixing in packages I do not maintain, and the complex build machineries of some packages can be a real timeconsuming pain in some body part. It is also frustrating when you end up spending hours trying to find a bug in the wrong sources. > 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. So for src:gcc-8 the preferred form of modification are three tarballs that are not even unpacked, and none of the patches applied? > It is almost certainly _not_ the state that source might get transformed > into at some point during the build process. Why not? It gets transformed into the sources that actually get built. These are the relevant sources when debugging some FTBFS or segfault. > 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. "different vendor's OS" is only a small part of the general problem. How should we handle architecture-specific patches properly inside Debian? This is part of the same general problem that the notion of exactly one "the sources" is misguided when it comes to what actually gets compiled. It is a real problem that there is no standard way to look on an amd64 machine at the src:gcc-8 sources that will actually get built on armel. And I cannot blame the maintainer, since there is no standard way to express things like e.g.: - "apply the Linaro patches only on arm* and only in Ubuntu" - "apply the Hurd patches that might touch generic code only on Hurd" > Cheers, Phil. 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
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
Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
On Sat, Aug 18, 2018 at 11:31:06AM -0700, Sean Whitton wrote: > Hello, > > On Fri 17 Aug 2018 at 07:36PM +0300, Adrian Bunk wrote: > > > The main misconception is that there would always be *the* source. > > > > Steps you might have before the compilation starts: > > 1. dpkg unpacks upstream sources > > 2. dpkg applies patches > > 3. debian/rules unpacks upstream tarballs as part of the build > > 4. debian/rules applies patches based on distribution > > 5. debian/rules applies patches based on release > > 6. debian/rules applies patches based on architecture > > > > What is "the source running on their Ubuntu system" for src:gcc-8? > > > > This package skips steps 1 and 2, but does all of steps 3-6. > > But all of steps 3--6 are part of the package build. > > "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? For a user it doesn't make a difference which tool applies the patches. 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. This implies that for these usecases you want to make possible dpkg would not require less conditional patching functionality - it would actually require more conditional patching functionality so that dpkg can give you the exact sources for the architecture you are looking at. Since we have established that conditional patching support is in any case required for your usecase, the vendor patching becomes less of an issue since this will anyways require even more tooling support for conditional patching. > 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
