On Mon, Feb 11, 2008 at 10:37:50PM -0800, Russ Allbery wrote: > > 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) > That isn't history. There isn't a chronological or derivational order, Uh, yes, there is an ordering -- the spec explicitly requires run-parts ordering. It might not be the ordering as originally developed; but a git tree isn't necessarily that either, thanks to rebasing, and nor is a darcs tree, thanks to merging and patch reordering. > I can switch to mathematics (somewhat) if that helps. A changeset > collection forms a bounded lattice. Uh, right... > No one is questioning that you can't do everything you might potentially > want to do with wig&pen. You can't create and maintain a package with wig&pen, even ignoring the other stuff. > The point is that wig&pen is a useful > interchange format that's useful now when we don't agree on what VCS to > use, My point is precisely that it's *NOT* useful now. The other VCS systems are, because they *have* the VCS backend you need to manage and manipulate history/changesets/patches/etc. Wig&Pen isn't, because it doesn't have those tools. > You can't work usefully work on a Git source package using bzr or quilt ...without converting from a git repository to a bzr or quilt repository. Likewise, you can't usefully on a Git source package with Wig&Pen without converting it to a Wig&Pen repository, with the extra disadvantage that tools to do that don't actually exist. > without losing the conceptual clarity of the changesets. You can work on > a wig&pen package in Git, bzr, or quilt while retaining that. I'm sorry, but you're mistaken. You _can't_ do that. If you wrote a whole bunch of tools to do it, you could, yes -- but you could do the same with git and bzr given the tools too; and as it happens tailor already exists and has that functionality. > That's the > difference, and the reason why it's not obvious to me that jumping > directly to a VCS is a good idea. Try creating and maintaining a package using git/bzr, and the git/bzr patches for dpkg. Try creating and maintaining the same package using wig&pen format. One's possible and easy, the other's not. > The VCS-based source format becomes very compelling once we all use the > same VCS, No, any VCS-based source format is compelling once you use a single VCS for a given package; and having it integrated into dpkg is immediately compelling for anyone who wants to be able to hack on a package as soon as they've downloaded and unpacked it. Trying to force a single VCS on every package is a non-starter, whether it's git, bzr or wig&pen. Different VCS's have different features: git's fast, bzr's good at merging, wig&pen's good at looking at by hand; git's hard to look at by hand, wig&pen has no tool support. Converting different VCSs to a single format for distribution is a good idea in theory -- hey, I was all for Wig&Pen back in 2005 -- but it turns out to be lossy, slow and difficult; and doesn't actually buy anything we can't already handle anyway. > Basically, a Git package is more useful than wig&pen if you're using Git, > and less useful than wig&pen if you're using anything else (except no > tools at all, in which case both are equally useful). It's not possible to automatically merge patches with wig&pen. It's not possible to automatically create a source package with wig&pen. No upstream uses wig&pen. No one else is writing tools for manipulating wig&pen. There are only two advantages to wig&pen: it doesn't suffer from NIH-syndrome, and it's easy to unpack by hand. > > 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. > This doesn't mean anything other than no one was interested enough by the > idea to implement it. If Raphael is now, I for one am going to cheer the > effort on, since wig&pen is more useful to me immediately than the Git > package format is. You have an odd definition of "useful to me immediately" when you're happy to apply it to something that doesn't work for anyone, but not to something that does work... > That doesn't mean that's all I want. I really want to see both. But I > will start using wig&pen *now*, No, you won't, because you *can't*. You can't even use dpkg to _create_ the packages to put on your own website. > whereas Git is going to take a while. Whereas you could do that, right now, at least for packages you're not uploading. You could do the same with at least bzr. > It's a useful intermediate step for me, and I don't think I'm alone. I'm > still far from convinced that Git actually replaces what quilt is capable > of it; I haven't used quilt, but I don't believe there's anything that would make it difficult to port Joey's git plugin to being a quilt plugin. > wig&pen in the model in which we're currently discussing it is not > something invented specifically by Debian for Debian. Uh, you're discussing something other than Wig&Pen then... If it helps, I was there when we started discussing this, and inventing something specifically for Debian, by Debian, is exactly what we were doing. > It is, for all > intents and purposes, a quilt patch series, which is something invented by > Linux kernel developers for doing almost exactly the same sort of work as > Debian packagers do. So great, I've nothing against quilt. But quilt isn't Wig&Pen, and forcing all DDs to switch from git, darcs, bzr, or whatever to quilt isn't ok, just because you like it. > Out of curiosity, have you ever seriously used quilt? [...] > It's a changeset manipulation tool, not a VCS. It's fundamentally > different than a VCS, even a VCS built on changesets like arch > (which I have also used). It is useful in precisely those circumstances > where changesets are useful first-class objects rather than simply > components in a VCS repository, which is a different mindset than using > a VCS. I don't consider that different to a VCS; just a more powerful one. It's certainly more powerful than Wig&Pen. darcs potentially allows the same behaviour, but the UI doesn't make it easy. If you can use quilt to implement a usable backend for Wig&Pen, more power to you. For the record, I haven't changed dak to accept Wig&Pen packages because when I tried, it was infeasible to make and maintain Wig&Pen packages, and since then no one else seems to have managed either, in the three years since Wig&Pen was originally designed. I haven't changed dak to accept git/bzr format packages because it's not in dpkg mainline, and dpkg in stable can't unpack them. AFAICS, that's not much more than a matter of merging into mainline to have that fixed by the end of the year. I'd love to see both those things fixed so we can upload packages in any format after lenny's released; but I'd hate to see git/bzr format get blocked on Wig&Pen, and then miss out on lenny because Wig&Pen just isn't up to snuff and have us end up with neither for another cycle. Cheers, aj
Attachment:
signature.asc
Description: Digital signature