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
Reply to: