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