Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
On Mon, Aug 20, 2018 at 04:51:30PM +0300, Adrian Bunk wrote: > On Mon, Aug 20, 2018 at 09:28:30AM +0200, Wouter Verhelst wrote: > > On Mon, Aug 20, 2018 at 12:15:00AM +0300, Adrian Bunk wrote: > > > How should we handle architecture-specific patches properly inside > > > Debian? > > > > Why should there ever be architecture-specific patches? > > > > I get that there sometimes need to be vendor-specific patches, because > > defaults may differ between distributions. But why on earth should > > defaults differ between architectures? That just makes no sense. Things > > like uintXX_t and htonl() should take away most architecture-specific > > differences, and then all that remains are things like ensuring > > alignment is done right. You don't need patches for that; you need > > bugfree code for that. > >... > > Are we discussing bugfree code or are we discussing reality? > > As an example, the non-release architectures of Debian are either > brand-new (riscv64) or fringe with usually brittle upstream status > in the toolchain (the other 13 non-release architectures). > > Now look at > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412 > > "Keywords: deferred" means "This bug was deemed too risky to attempt to > fix during stabilization stages. Deferred to a development stage of a > subsequent release." AKA "Target Milestone: 9.0" > > The bug seems to be rare enough on x86 to warrant that. > > On ia64 this bug breaks most code that builds with -O3, > Qt and Pyhon 3.7 were among the first FTBFS. > > The fix will likely be in generic code in gcc. Yes, but there's a huge difference here. Compiling code for a given platform is not the same thing as running on said platform. If the compiler runs correctly, then it doesn't matter which platform it runs on; it's still the same compiler. The architecture-specific issues that I was talking about, when they occur in a compiler for a platform, can be patched perfectly safe, with or without the agreement from upstream. If you see that a compiler misbehaves when compiling *on* platform X but not when compiling *on* platform Y (but in both cases compiling *for* platform Z), then you need to fix the code on all platforms -- the ones where it is broken as well as the ones where it is not broken -- and ship the fixed code. Hopefully to upstream too, but definitely to Debian. The architecture-specific code in a compiler that occurs when compiling for a given platform needs to be built into *any* compiler which produces code for that platform; so, not just in src:gcc-X, but also in src:gcc-X-cross and src:gcc-X-cross-ports. So even if we were to add code to dpkg-source to support architecture-specific patches (which we don't currently and which I think we definitely shouldn't), then this still wouldn't help the GCC packages in Debian. [...] > And this can happen even on release architectures in a release. > In src:gcc-6 the fix for #727621 [2], which is required for > building LLVM on armel, is applied only on armel in stretch. No; it is applied only on compilers that produce armel *output* in stretch. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I'm maintaining two packages which have Ubuntu-specific patches, which have been imported by Ubuntu maintainers giving a hand here in order to reduce the diff with Ubuntu and maintain the packages in the same place. I don't have strong opinions on this, but if it's suddenly forbidden, someone (not me) has to find a way that works for derivatives and doesn't end up multiplying sources packages, because I think we'll lose in the end. On Mon, 20 Aug 2018 09:28:30 +0200 Wouter Verhelst wrote: > On Mon, Aug 20, 2018 at 12:15:00AM +0300, Adrian Bunk wrote: > I think, however, that "changing the defaults to make sure it matches > the one for this vendor" should be done as part of the build, if at all. > Doing it as part of unpacking the source is just wrong. When I run > "dpkg-source -x", I expect it to behave as would "unzip" or "tar x". To > have it act differently depending on the environment in which it is run? > That's just perverse. I have read this multiple time in this bug. To be it looks like you're advocating dpkg-source *not* to apply any patches to upstream sources, then. To be honest, I think I liked it better when patches were actually applied during the build and not during source extract. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlt7Dl4ACgkQ3rYcyPpX RFu48wf7BMQoO9SvDki0/jh5KbrBo/FgrqrDKlAZzh9kKgHKfNmrnRsmbH15dcL5 7RMaF0OOXNLLXJhuFb2U7pR1/Y8UoSdaBM1lFqquX5FUldkz69b+3qJxK6oaXj5Q 7vm3IlIE2E1NqjQv70QKW6oZLXQ5HcNODurt38SKkuVNIcpcdfwY4j4T8KOA//Xk t3JVgzSWJfIei+Bqvz+KyQP9IzE9QCQ+szX+3TB7fuafn6FL8PSRHDvQO4Q1wCOJ W37TiUzuzj7ua7QNqq80cLmwJe6IeQoj3GAlPJRFcg+CCXoEOHVt8WUA7TgLUwT2 kfvpQ1IonB/ThkRy49BYnklWfGY5nQ== =mEqN -END PGP SIGNATURE-
Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
On Mon, Aug 20, 2018 at 09:28:30AM +0200, Wouter Verhelst wrote: > On Mon, Aug 20, 2018 at 12:15:00AM +0300, Adrian Bunk wrote: > > How should we handle architecture-specific patches properly inside > > Debian? > > Why should there ever be architecture-specific patches? > > I get that there sometimes need to be vendor-specific patches, because > defaults may differ between distributions. But why on earth should > defaults differ between architectures? That just makes no sense. Things > like uintXX_t and htonl() should take away most architecture-specific > differences, and then all that remains are things like ensuring > alignment is done right. You don't need patches for that; you need > bugfree code for that. >... Are we discussing bugfree code or are we discussing reality? As an example, the non-release architectures of Debian are either brand-new (riscv64) or fringe with usually brittle upstream status in the toolchain (the other 13 non-release architectures). Now look at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412 "Keywords: deferred" means "This bug was deemed too risky to attempt to fix during stabilization stages. Deferred to a development stage of a subsequent release." AKA "Target Milestone: 9.0" The bug seems to be rare enough on x86 to warrant that. On ia64 this bug breaks most code that builds with -O3, Qt and Pyhon 3.7 were among the first FTBFS. The fix will likely be in generic code in gcc. Should the gcc maintainer apply a backport of a non-architecture specific change to the compiler used in the buster release, if upstream considers it too risky for the gcc 8 branch[1] and the fix is important only for a non-release architecture? Applied only on ia64 the situation is different. On ia64 the alternative would be a lot of FTBFS bugfixing work with workaround patches submitted to a three digit number of packages. And this can happen even on release architectures in a release. In src:gcc-6 the fix for #727621 [2], which is required for building LLVM on armel, is applied only on armel in stretch. cu Adrian [1] perhaps the fix for this specific bug will turn out to be simple, but let's assume there will be a fix and it will not be backported to the upstream gcc 8 branch [2] https://sources.debian.org/src/gcc-6/6.4.0-20/debian/patches/pr64735.diff/ -- "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
On Mon, Aug 20, 2018 at 12:15:00AM +0300, Adrian Bunk wrote: > How should we handle architecture-specific patches properly inside > Debian? Why should there ever be architecture-specific patches? I get that there sometimes need to be vendor-specific patches, because defaults may differ between distributions. But why on earth should defaults differ between architectures? That just makes no sense. Things like uintXX_t and htonl() should take away most architecture-specific differences, and then all that remains are things like ensuring alignment is done right. You don't need patches for that; you need bugfree code for that. I think, however, that "changing the defaults to make sure it matches the one for this vendor" should be done as part of the build, if at all. Doing it as part of unpacking the source is just wrong. When I run "dpkg-source -x", I expect it to behave as would "unzip" or "tar x". To have it act differently depending on the environment in which it is run? That's just perverse. [...] -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
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
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. -- Sean Whitton signature.asc Description: PGP signature
Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
On Fri, Aug 17, 2018 at 07:33:02PM +0100, Ian Jackson wrote:
> Adrian Bunk writes ("Bug#904302: Why outlawing vendor-specific patch series
> would be a bad idea"):
> > 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
>
> I disagree that (4) should ever be relevant. There should never be
> any patchese applied conditionally based on dpkg-vendor, for the
> reasons I explained very recently in response to the liferea example./
>
> We don't ever do (5), do we ? Please tell me we don't. We can have
> different source code in our different releases.
For packages like src:firefox-esr the same source code might
be maintained to support releases ranging from oldoldstable to
unstable - 52.8.0esr-1~deb7u1 is a security update for wheezy
that is technically a backport of a package in buster/sid.
I do not know whether firefox-esr does patching based on release right
now, but this is a case where one package is being used to provide
security support for up to 4 different Debian releases at the same time.
I would also not be surprised if some package would do different
patching based on release for easy rebuilding in stable-backports,
this would sound like a natural solution to me.
> I can see that (6) might be needed in some exceptional cases but
> normally there is a better way.
As I said, src:gcc-8 does all of steps 3-6.
Much of the relevant code is in
https://sources.debian.org/src/gcc-8/8.2.0-4/debian/rules.patch/
Things are even more interesting due to this being a debian/ shared
between Debian and Ubuntu which are using different upstream sources.[1]
> Ian.
cu
Adrian
[1] GFDL
--
"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 ("Bug#904302: Why outlawing vendor-specific patch series
would be a bad idea"):
> 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
I disagree that (4) should ever be relevant. There should never be
any patchese applied conditionally based on dpkg-vendor, for the
reasons I explained very recently in response to the liferea example./
We don't ever do (5), do we ? Please tell me we don't. We can have
different source code in our different releases.
I can see that (6) might be needed in some exceptional cases but
normally there is a better way.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
On Fri, Aug 17, 2018 at 08:58:49AM -0700, Sean Whitton wrote: > Hello, > > On Fri 17 Aug 2018 at 12:01AM +0300, Adrian Bunk wrote: > > > 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 is not a "reasonable expectation", this is a bogus assumption. > > And users should be clearly told that investigating Ubuntu problems > > on a Debian system is not a good idea - the supported way for that > > is a chroot (or some more sophisticated virtualization solution). > > People don't expect that running dpkg-buildpackage on a Debian system > would get them the binary package running on an Ubuntu system. That's > different from the expectation that the source they get is the source > running on their Ubuntu system. 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. After step 2 you have 3 upstream tarballs plus a debian/ with a pretty sophisticated custom machinery - that's not useful for seeing what gets built. If you want to look after step 6 at the source "running on your system", what you will see depends on your: - distribution: Debian or Ubuntu? - release: stretch or buster/sid? - architecture: amd64 or arm64? > 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, On Fri 17 Aug 2018 at 12:32PM +0100, Ian Jackson wrote: > In general, I think package builds should not pay any attention to > dpkg-vendor. Can I please add that request to the TC's deliberations ? This is about package builds, not the unpacking of source packages, so is surely a completely separate issue (which we should discuss at the level of Debian Policy, not refer directly to the T.C.). -- Sean Whitton signature.asc Description: PGP signature
Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
Hello, On Fri 17 Aug 2018 at 12:01AM +0300, Adrian Bunk wrote: > 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 is not a "reasonable expectation", this is a bogus assumption. > And users should be clearly told that investigating Ubuntu problems > on a Debian system is not a good idea - the supported way for that > is a chroot (or some more sophisticated virtualization solution). People don't expect that running dpkg-buildpackage on a Debian system would get them the binary package running on an Ubuntu system. That's different from the expectation that the source they get is the source running on their Ubuntu system. -- Sean Whitton signature.asc Description: PGP signature
Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
Iain Lane writes ("Bug#904302: Why outlawing vendor-specific patch series would
be a bad idea"):
> On Fri, Aug 17, 2018 at 09:49:00AM +0200, Tollef Fog Heen wrote:
> > > One obvious solution if vendor-specific series files get outlawed in
> > > Debian would be to switch from ubuntu.series to manual patching in
> > > debian/rules based on dpkg-vendor(1).
> >
> > Or it would mean that Ubuntu would carry a XubuntuY version and do
> > manual (or automatic, based on whatever tooling they have available)
> > merges from Debian, marking it clearly as a different work.
Quite.
If an Ubuntu user downloads the liferea source code from Debian, to
see what Debian's version is like, they should *not* get the Ubuntu
branding and default feed changes.
What this example shows is that, when a derivative wants a program to
behave differently for these kind of reasons, this should generally be
done by *actually changing the source code*.
Ubuntu already has machinery for automatically merging from Debian.
That machinery should be used. And improved, if necessary.
> I would like you to consider - and I think this is part of what Adrian
> is raising too¹ - this kind of case where the Debian maintainer *wants*
> to support particular derivatives in their source package in Debian and
> is willing to test it properly.
The matter might be different for changes which are to deal with the
presence or absence of particular things in the derivative. In that
case, the change can simply be made to Debian. But it should be
conditional not on dpkg-vendor, but on whatever the actual difference
is.
In general, I think package builds should not pay any attention to
dpkg-vendor. Can I please add that request to the TC's deliberations ?
> Having this facility avoids the need for any kind of source package
> delta resolution process needing to take place
This is, of course, false.
The vendor series file *is a source package delta resolution process*.
It's just a terrible one.
> which might add arbitrary delays between a new package being
> uploaded to unstable and becoming available in the derivative's
> unstable suite.
If new updates are not be merged automatically, by a robot, in a
timely way, then that is a tooling problem.
Note that if there is a vendor series, *other* changes made in Debian
to the upstream files in the package will be silently ignored.
This is incredibly counterintuitive and undesriable.
> TBH I'm not sure what I'd ask -ctte to do with this argument. If you do
> decide to outlaw the vendor-specific series, maybe advice (6.1.5) to
> relevant developers to consider designing a way to better support
> derivative specific patches within Debian.
"Derivative-specific patches" covers two kinds of changes:
1. Changes which are direct differences of policy or preference in the
derivative, such as changes to the default liferea feeds, or changes
to which package(s) are available.
2. Changes which are consequential on other changes. Eg, changes to
cope with different (build-)dependencies.
No changes of type (1) should never appear in Debian source packages,
for the reasons I have explained. Therefore the mechanism you are
suggesting "relevant developers" should design ought not to exist.
Instead, if carrying patches downstream is too hard, that should be
fixed. And indeed I and others are working on that.
Changes of type (2) should be ideally be dealt with by detecting the
situation at build-time where possible, but that should be done by
looking at which of the alternative build dependencies is installer,
or whatever, not by checking dpkg-vendor.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
On Fri, Aug 17, 2018 at 09:49:00AM +0200, Tollef Fog Heen wrote: > > One obvious solution if vendor-specific series files get outlawed in > > Debian would be to switch from ubuntu.series to manual patching in > > debian/rules based on dpkg-vendor(1). > > Or it would mean that Ubuntu would carry a XubuntuY version and do > manual (or automatic, based on whatever tooling they have available) > merges from Debian, marking it clearly as a different work. I would like you to consider - and I think this is part of what Adrian is raising too¹ - this kind of case where the Debian maintainer *wants* to support particular derivatives in their source package in Debian and is willing to test it properly. Having this facility avoids the need for any kind of source package delta resolution process needing to take place², which might add arbitrary delays between a new package being uploaded to unstable and becoming available in the derivative's unstable suite. It means that the Debian uploader does not need to become - or to find - a derivative uploader to perform this resolution. And it avoids maintainers having to cook up their own solution if they want to do it at build time without tool support. FAOD I am not challenging that the drawbacks of vendor-specific patch series as outlined in this bug exist - just saying that Adrian's point has some merit in that having this *kind* of support (perhaps not this specific implementation) easily available is useful. TBH I'm not sure what I'd ask -ctte to do with this argument. If you do decide to outlaw the vendor-specific series, maybe advice (6.1.5) to relevant developers to consider designing a way to better support derivative specific patches within Debian. Cheers for handling this issue, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] ¹ sorry for putting words in your mouth if this isn't what you meant :-) ² in Ubuntu's case this is not automatic; a human uploader needs to at the very least review the output of merge-o-matic). signature.asc Description: PGP signature
Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
On Fri, Aug 17, 2018 at 09:49:00AM +0200, Tollef Fog Heen wrote: > ]] Adrian Bunk > > > Hi, > > > > looking at something where I worked on the upstream implementation ages ago: > > https://sources.debian.org/src/liferea/1.12.4-1/debian/patches/ubuntu-example-feeds.patch/ > > > > It is a common problem that users should be able to get started quickly > > after installing a program. > > > > When liferea is started by a user for the first time, the default feedlist > > in the locale of the user gets installed as feedlist for the user. > > > > It is clear why a derivative, especially a brand-aware one like Ubuntu, > > wants to change this feedlist. > > > > And it is also clear why this change cannot be applied in Debian. > > > > One obvious solution if vendor-specific series files get outlawed in > > Debian would be to switch from ubuntu.series to manual patching in > > debian/rules based on dpkg-vendor(1). > > Or it would mean that Ubuntu would carry a XubuntuY version and do > manual (or automatic, based on whatever tooling they have available) > merges from Debian, marking it clearly as a different work. That's why I wrote: > On the more general point, there is no actual rationale given why the > TC should discuss outlawing vendor-specific patch series without also > discussing manual debian/rules patching in 3.0 (quilt) packages based > on dpkg-vendor(1) or other mechanisms. If vendor-specific patching (and configuration?) should move from Debian to deltas carried permanently by derivatives, then this should be discussed and decided for the general case. Outlawing a non-buggy patching implementation will in practice only result in the same patching being done with per-package patching implementations. These are more likely to be buggy, and make it impossible to easily search for all packages doing it. > [...] > > > The whole underlying notion that there would be one source tree that > > gets built is also flawed. This is not true in all cases, and can > > never be. > > We are not talking about what's built. We're talking about what's > unpacked. It's well understood that what's unpacked is not always > what's built; build processes can (and do) all kinds of transformations > and is understood to be executable code. Is it really well understood? A large part of the email that opened this bug only makes sense under the assumption that a TC decision will result in what is being unpacked becoming what will be built. More exactly, the part from "And secondly" up to and including the section discussing "#ifdef ubuntu". For arguments like "will get them the code running on the Ubuntu system" or "#ifdefs are visible in the actual source code" it doesn't matter whether the different patching based on the distribution will be done by dpkg or debian/rules, and the same applies to debian/rules patching based on the release or the architecture. 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 > Hi, > > looking at something where I worked on the upstream implementation ages ago: > https://sources.debian.org/src/liferea/1.12.4-1/debian/patches/ubuntu-example-feeds.patch/ > > It is a common problem that users should be able to get started quickly > after installing a program. > > When liferea is started by a user for the first time, the default feedlist > in the locale of the user gets installed as feedlist for the user. > > It is clear why a derivative, especially a brand-aware one like Ubuntu, > wants to change this feedlist. > > And it is also clear why this change cannot be applied in Debian. > > One obvious solution if vendor-specific series files get outlawed in > Debian would be to switch from ubuntu.series to manual patching in > debian/rules based on dpkg-vendor(1). Or it would mean that Ubuntu would carry a XubuntuY version and do manual (or automatic, based on whatever tooling they have available) merges from Debian, marking it clearly as a different work. [...] > The whole underlying notion that there would be one source tree that > gets built is also flawed. This is not true in all cases, and can > never be. We are not talking about what's built. We're talking about what's unpacked. It's well understood that what's unpacked is not always what's built; build processes can (and do) all kinds of transformations and is understood to be executable code. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
Hi, looking at something where I worked on the upstream implementation ages ago: https://sources.debian.org/src/liferea/1.12.4-1/debian/patches/ubuntu-example-feeds.patch/ It is a common problem that users should be able to get started quickly after installing a program. When liferea is started by a user for the first time, the default feedlist in the locale of the user gets installed as feedlist for the user. It is clear why a derivative, especially a brand-aware one like Ubuntu, wants to change this feedlist. And it is also clear why this change cannot be applied in Debian. One obvious solution if vendor-specific series files get outlawed in Debian would be to switch from ubuntu.series to manual patching in debian/rules based on dpkg-vendor(1). There are two problems: First, it replaces a working standard dpkg feature with an own package-specific implementation. There are surprisingly many things a maintainer can get wrong, like some other packages doing debian/rules patching where this breaks building twice in a row. Second, it hides the whole situation/problem. Finding all packages that use vendor-specific patch series is simple and has been done in this discussion here. This makes it also simple to find bogus cases where the change should actually be applied in Debian (or upstream). How do you find all 3.0 (quilt) packages that have conditional patching implemented in debian/rules? On Mon, Jul 23, 2018 at 09:22:17AM +0800, Sean Whitton wrote: > There is a broader question of whether source packages should be allowed > to unpack differently on different systems through other means, such as > patch systems implemented in debian/rules (this could be done using > dpkg-vendor(1)). But given that 3.0 (quilt) is now dominant, you might > leave this broader question aside. I could name a 3.0 (quilt) package where Sean Whitton has done a maintainer upload this year that has a patch applied conditionally in debian/rules with a not completely correct patching mechanism. The name of the package has not been mentioned in this bug so far. On the more general point, there is no actual rationale given why the TC should discuss outlawing vendor-specific patch series without also discussing manual debian/rules patching in 3.0 (quilt) packages based on dpkg-vendor(1) or other mechanisms. The whole underlying notion that there would be one source tree that gets built is also flawed. This is not true in all cases, and can never be. 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 is not a "reasonable expectation", this is a bogus assumption. And users should be clearly told that investigating Ubuntu problems on a Debian system is not a good idea - the supported way for that is a chroot (or some more sophisticated virtualization solution). I do not see how this could ever work for a package like src:gcc-8, that is based on several upstream tarballs and then patches and configures the code differently based on: - distribution - codename of the distribution - architecture It might be too complex and not worth the effort, but if anything should be changed it should actually be changed in the opposite direction: Replace buggy patching systems implemented in individual packages with a standard non-buggy implementation in dpkg that supports more ways of conditional patching. 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
