Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]
Sam Hartman writes ("Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]"):
> So imagine that Ubuntu and several other downstreams care more about
> security and hardening than they do about backward compatibility and
> they choose to change a number of gcc and other tool defaults in support
> of that. I realize my example is not entirely hypothetical, but I want
> to emphasize I have not researched to get all the details right, because
> it doesn't matter.
>
> Especially if multiple downstreams or individual users who build from
> source might want the change, I think carrying the delta in the Debian
> source package can be valuable. It needs to be balanced against a lot
> of other concerns.
I agree that carrying a switch-on-able delta in the Debian package
would be a good thing there. So, the meat of the change should
definitely go to Debian or maybe even to upstream as a
--with-extra-hardening configure option or some such.
This should be enabled via DEB_BUILD_OPTIONS, or a commented-out line
in the rules file, or by reading /etc/compilers/hardening-enabled at
build- or runtime, or something. Not by looking at `the vendor'.
A scenario why this is needed can be seen from this scenario:
Suppose someone wants to try to maintain a distro which is like
Debian, but which takes some subset of packages from Raspbian.
The obvious way to do this is to import most packages from Debian and
the other packages from Raspbian, and to fix up the bugs which occur
at the interface.
If packages in Debian and Raspbian use dpkg-vendor --is raspbian to
decide whether to do the Raspbian thing, then there is no way to make
this work because there is no correct answer: the answer to whether a
package should do the Raspbian thing depends not only on which distro
we are building or running on, but on which package it is.
In practice if I were maintaining that distro I would be tempted do
some kind of hideous hack to make the output of dpkg-vendor depend on
the name of package we were building. Because how else will I do it ?
Playing whack-a-mole with dpkg-vendor calls would be impractical.
If the Raspbian-specific features are enabled by carrying a changed
source package in Raspbian, then things will mostly DTRT and generally
problems will occur only when the delta-enablement is done via some
kind of indirection, and the indirection messily crosses the `cutoff'
between the Raspbian-originated and Debian-originated packages.
Ie I only have to manually fix the problems that irreducible, not ones
introduced by ill-advised calls to dpkg-vendor.
> And yes, in many cases dgit is the answer. That said, if I were
> maintaining the same package both for Debian and for the downstream I
> work on, I might well value having a single source tree enough to use
> dpkg-vendor or lsb-release or something to switch.
In that case, that is convenient for you but it is wrong for your
downstreams and users. We should be discouraging such tradeoffs.
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: