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 [[email protected]]
