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 Jackson <ijackson@chiark.greenend.org.uk> These 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.
Reply to: