Colin Watson writes ("Bug#904302: Whether vendor-specific patch series should be permitted in the archive"): > ... 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).
Obviously I agree with the conclusion, but I would like to propose a different way of looking at this: The Debian archive and derivative archives, and the .dsc source package formats, including "3.0 (quilt)" currently including the vendor series feature, *are a version control system*. [1] The vendor series feature *is a way to represent a branch*. We should consider its merits in those terms, by comparing it to other technology we have for handling branches. In the current system [1], the obvious competing way to represent a branch is for the derivative to actually change the source package. If vendor series are forbidden, the same effect can always be achieved that way. Compared to changing the source package, the vendor series appears to offer a reduction of maintainer friction. This is a relatively minor benefit. (Note that resolution of any merge conflicts during rebase, or whatever, is still necessary; the only benefit is a small degree of automation and a slight reduction in different files etc. on maintainer systems.) However, that convenience comes at too high a price. In particular, the invisibility of the vendor series - that very lack of friction - means that the vendor series is often wrong. Conversely, derivatives must already have means for merging or rebasing their own delta-represented-as-changes-to-the-source-package, so as to track Debian. (Vendor series cannot, for example, represent changes to files in debian/.) Those mechanisms are often fairly well developed, and if they are insufficient they need to be improved [2]. And people can inspect the differences by comparing source packages. So I think it is nearly always better, even without considering global effects, to represent any needed derivative delta as a changes source package, than to represent it as a vendor series.[3] But forbidding vendor series has the global benefit that no-one who deals with source packages from Debian derivatives has to write code to deal with, and spend mental energy on, yet another way to represent the delta. Thanks, Ian. [1] By modern standards, an appallingly bad one. I would argue that it all made sense in 1993 (when the best alternative was CVS) but nowadays we have much much better tools. This is why I am engaged in a project to provide something much better than .dsc, based on git. [2] Tracking Debian is IMO still too hard. I am working on that. [3] That does not mean I think that changing the source package is always or even mostly the best answer; often other approaches will be better still. It just means that vendor series are worse than changing the source package. -- Ian Jackson <ijack...@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.