On Mon, Feb 11, 2008 at 08:26:23PM -0800, Russ Allbery wrote: > Anthony Towns <[EMAIL PROTECTED]> writes: > > I think it's a mistake to separate those -- our source package format is > > a VCS system; if wig&pen happens to be a more suitable VCS, that's fine, > > but it's not inherently superior or inferior to any other VCS, just > > because it happens to be Debian-specific. > I very strongly disagree with this use of terminology.
A VCS is a system for controlling (managing, distributing) versions of a repository. A Debian source package is a repository. We want to make multiple versions of that repository available (in particular, a history from the last upstream version to the current Debian revision, so that it's possible to separate each change). You can disagree however strongly you like, but viewing Debian source packages as a VCS isn't a particular stretch, and, IMO, gives a much better overall perspective for looking at what we're trying to achieve; and for that matter, why Wig&Pen didn't achieve it. > Our source package format is not a VCS system currently. Yes, it is; the problem is that it naturally only supports two versions (upstream and Debian), and has further limitations on how they can differ. (Or if you're looking at native packages, only one version) > It is a way of > representing two works that combine into a source package, but thinking of > that as a VCS just results in a bunch of conclusions that muddy the whole > issue. There is no history, and history is the entire point of a VCS. There _is_ history, both in the form of debian/changelog, which descriptively goes back beyond the actual code changes that are represented, and the single step back to upstream. And history is _precisely_ what we're interested in extending, whether by dbs/dpatch/whatever, wig&pen, git, bzr or otherwise. > wig&pen isn't a better VCS; it's a better way of representing the current > state of the tree. It still doesn't have any history. It does have history: upstream: (unpack all the tarballs) upstream+1: (apply the first patch from .debian.tgz /patches) upstream+2: (apply the second patch from .debian.tgz /patches) ... debian: (apply the last patch from .debian.tgz /patches) > It simply doesn't > bundle together all of the changes into one blob of "Debian work" and > instead presents a bunch of separately appliable and analyzable changes. Which is exactly what "history" is. > When we call that a VCS, we get into endless arguments about how we should > use a real VCS, The reason why Wig&Pen has never worked is precisely because it's not a real VCS: it's just a repository format, it doesn't have the tools to manage a repository. Which means it's not possible to create and maintain a package in Wig&Pen format, which is why it's not actually usable, inside or outside of Debian. For example, you talk about "separately analyzable" changes -- but wig&pen doesn't give you that: its changes are ordered to allow multiple changes to affect a single file, and unlike tools like darcs, there isn't any automated way to deal with dealing with corner cases when rearranging changesets; let alone merging changesets. You ask later: > Am I able to upload a wig&pen source package right now? My impression was > that it was never tried. Are you able to use the .git source package format right now? Yes, you grab Joey's sources, create a package with git, and you're done. You can't upload it to the archive, because it's not supported by dpkg in stable, but that's it. By contrast, you can't even get that far with Wig&Pen. And the reason is that you've got a new VCS format, without the tools to go with it. > how people don't want to dumb down their VCS into a patch > format, and so forth, which are all red herrings created by the mistaken > terminology. Using a real VCS with a more powerful change representation than textual diffs has benefits; discussing those benefits isn't "endless arguments" about "red herrings". > If our source format is like anything, it's like a > changeset or collection of changesets in the old arch definition, with no > ordering and no history. Our current format is a single changeset, yes. Wig&Pen does introduce ordering ("via the same rules as run-parts") and does introduce history, just as git, bzr, or any other VCS with multiple versions does. > It is, in other words, an interchange format. > If we present it in that fashion, we avoid a lot of futile discussions. Interchange is an important part of a VCS, yes. Which is one reason to use existing VCS formats (like tar+patch, like git, like bzr, etc), instead of creating our own. Treating the "dpkg source format" as something different to a VCS, even though it happens to have almost the exact same requirements, leaves us open to the trap of thinking whatever we invent, as Debian specialists, is going to naturally be more suitable than existing solutions. It's not. > > ie, "that can be used to covert from the VCS used in development to > > wig&pen VCS". > This is not what those scripts do. If they did that, they'd retain > history, which is entirely not the point. History is exactly the point of the debian/patches behaviour specified by wig&pen. If you've got an "interchange format" that can be converted to and from a "VCS format", all you've done is create another VCS format. Don't get me wrong, it might be a *better* format for some purposes -- Wig&Pen is good for manual inspection in particular -- but it's just another competitor in the same field, and doesn't deserve to be treated as innately superior. > I agree with Raphael: wig&pen has more immediate appeal for widespread > adoption than a VCS-based system, That appeal is fundamentally misplaced: getting wig&pen to be immediately useful requires developing VCS-equivalent tools to manage and create wig&pen format packages which already exist for git/bzr/etc format packages. In the three years Wig&Pen's existed, those tools haven't been created, while the tools for managing git/bzr/etc repositories have not only existed but been continuously improved. > even if a VCS-based system is better in > the long run. This is easily seen by looking at the archive. wig&pen is > essentially what everyone who is using quilt or dpatch is already doing. > It's a standardization of current practice, which is always easier. It's not even that, because it works differently to all those systems, in ways that change people's workflow and come close to requiring just repackaging from scratch. Don't get me wrong -- if you want to work on wig&pen please go right ahead, and good luck. Just don't mistake it for fundamentally more appropriate source format for Debian than any of the others that've been proposed: it's not -- and treating it as though it is has a damn fine chance of delaying or outright blocking better solutions. Cheers, aj
signature.asc
Description: Digital signature