Bug#904302: Whether vendor-specific patch series should be permitted in the archive
On Sat, Jul 28, 2018 at 02:18:51AM +1000, Stuart Prescott wrote:
> Debian does not micromanage its maintainers and Debian most certainly does
> not tell derivatives what to do; however, that is precisely what this
> proposal is requesting.
Is it? What I see is more like a derivative (or at least some of its
developers; Ubuntu has not had a formal discussion about this and I'm
sure we don't have unanimity) asking that Debian update its source
package standards to forbid a feature that was implemented with the best
of intentions to make that derivative's life easier, but which has in
fact turned out to have the reverse effect.
It's technically true that Ubuntu could individually decide to patch out
this feature in both dpkg and all of the source packages that use it,
and that we haven't not done so. That's mainly because it would be a
fair amount of work, not to mention that the patches would be of a
really strange shape (removing ubuntu.series in an Ubuntu patch ...).
Furthermore, since the feature was originally there mainly to improve
collaboration with Ubuntu, or at least that's mostly how it's ended up
being used, if Ubuntu doesn't think it's working well in practice then
Debian processes are *exactly* the correct way to discuss it. The
alternative is a bizarre ping-pong game of patch management behaviour
that would be very confusing for everyone outside the small group of
people up to speed with it, and that would do nobody any good in the
long run.
> Debian should not seek to prevent maintainers doing something that
> they have agreed to do in collaboration with downstreams.
My memory of the origin of this feature is that the dpkg developer who
originated it asked me if it might help with upstreaming changes from
Ubuntu to Debian, I said something along the lines of "uh, maybe, I
guess, it sounds like that would have some problems?", and then they
went ahead and did it. I don't *think* it was originally a request that
came from derivatives, and I don't remember the sort of collaborative
design that I think you're suggesting here.
I admit that we in Ubuntu didn't push back as hard as in retrospect we
should have done, and some people were positive about the idea; but at
the time, there were a lot of ideas floating around about how to make
the process of upstreaming patches better, and while many of them were
helpful it would have been hard to manage a 100% hit rate. (dpkg-vendor
and related features were implemented around the same time, and I think
those were a good idea and have been helpful.)
That said, it was some time back and I haven't been able to find any
actual transcripts of the conversation, so I'm relying on fallible human
memory and will gladly apologise if I'm wrong. Still, this sort of
design decision should still be open to being revisited when it turns
out to have serious problems in practice.
> One might find vendor.series to be a poor technical solution, but then
> those who find it abhorrent might seek to find a better one, rather
> than attempt to resort to administrative power.
I think Steve and I, at least, have both made it clear what we think
would be better: briefly, apply patches unconditionally but if necessary
give them conditional behaviour that can be controlled at build time.
While this occasionally means making the patch a bit more complicated,
it simplifies management of the patch *series*, and avoids a whole
category of problems that maintainers make in practice. (Certainly I've
been saying essentially this for years when people ask about this kind
of thing on #ubuntu-devel.)
However, features built into the source package format are tempting for
maintainers to use, and so we end up playing whack-a-mole. The only
good fix for that is to remove the feature. It doesn't require a
replacement at the level of the source package format, but it would
require ensuring that packages stop using the feature first, and that's
the kind of interoperability issue that requires a change in policy.
Even if policy doesn't jump straight to forbidding the use of
vendor-specific series, it would make things very much easier if it were
to formally deprecate them.
To me, this is similar to the DEB_AUTO_UPDATE_DEBIAN_CONTROL feature in
CDBS. That was also introduced with good intentions to try to make
maintainers' lives easier, and it was tempting enough that for a while
quite a few people used it; but it proved to have deleterious
side-effects and so was deprecated. (I think this was only ever
deprecated at the level of Lintian and the ftpmaster REJECT-FAQ rather
than actually in policy, but the basic idea seems similar.)
> Essentially, this is a request that the TC overrule both Debian maintainers
> *and* derivative maintainers in what they have agreed as a workflow that
> obviously works for them.
Again, this is a misstatement of what derivative maintainers have in
fact decided, except perhaps by omission.
Some individual package maintainers who care about some derivatives have
made the decision to use this feature. That's not the same thing.
> Today, Debian decides to not allow debian/patches/vendor.series, then
> tomorrow, a derivative patches dpkg-source and Debian is asked to
> decide whether debian/patches/vendor-dammit-i-
> want-these-patches-applied.series is allowed in the source package.
A robust decision on this policy question ought to include documenting
the rationale for deprecating the feature, and writing that down in
policy for future travellers so that they can learn from the mistakes of
the past would help to forestall this hypothetical situation. My
opinion from experience with this feature is that those derivative
maintainers would have an easier time if they used patches with
conditional behaviour (or maintained a local branch, of course, although
that was part of what source package management features like this were
trying to reduce).
I'm aware my comments here are mostly Ubuntu-specific; this is not only
because it's what I have most experience of, but also because I'm pretty
sure that ubuntu.series is the only kind of vendor series I've ever seen
in Debian source packages. It's possible I've missed some.
--
Colin Watson [cjwatson@debian.org]
Reply to: