On Mon, Feb 11, 2008 at 08:26:23PM -0800, Russ Allbery wrote:
> Anthony Towns <aj@azure.humbug.org.au> 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
Attachment:
signature.asc
Description: Digital signature