Re: problems with 3.0 format
On Fri, Mar 26, 2010 at 11:50:40AM +0100, Bernhard R. Link wrote:
> * Benjamin Drung <bdrung@ubuntu.com> [100326 01:54]:
> > 1. It's a bit awkward to set things up when checking out from
> > revision control; I didn't really want to check in the .pc
> > directory, and the tree checks out in the patched state (as it
> > should), so I needed some way for developers to get quilt
> > working easily after a checkout. This is sort of the reverse of
> > the previous problem, where users had to do something special
> > after dpkg-source -x, and I consider it less serious so I'm
> > willing to put up with it. I ended up a rune in debian/rules
> > that ought to live somewhere more common.
>
> I think what quilt is missing here, is some reverse-setup: A command
> to create a .pc file from a patched tree and a series of patches.
Are you suggesting specifically here that this should go in quilt? I
wouldn't be opposed to that; I'd been thinking of dpkg-dev, but either
would work.
> Another way to work around that is not using quilt if you are using
> a vcs, but use the vcs to manage the differences and export that
> information into debian/patches/.
> For git I wrote git-dpm[1] as some way[2] to do this. I guess with bzr
> something similar should be possible.
I know some people have been looking at this, and I recognise that in
many ways it would be better to regard the patches as exports from a VCS
(indeed, I mentioned this in my blog article). However, for me, I'd
foresee many more warts than the mere management of branches and
extraction of patches from them. For instance, I would want to commit
debian/changelog at the same time as the patch (I don't like
autogenerating debian/changelog; the results tend to be terrible), which
means I'd have to either tolerate lots of conflicts or else put up with
auto-merging tools, which I never really trust very much. Also there's
the issue of DEP-3 metadata in patch files, which I'd often want to
change along with the commit to their contents. Probably all soluble
but all the tools I've seen are very definitely in their early stages as
yet.
It seems to me that I could easily end up spending all the time I save
on playing with tools, which isn't really what I want to be doing.
> > 2. Although I haven't had to do it yet, I expect that merging new
> > upstream releases will be a bit harder. bzr will deal with
> > resolving conflicts in the patched files themselves, and that's
> > why I use a revision control system after all, but then I'll
> > have to go and refresh all the patches and will probably end up
> > doing some of the same conflict resolution a second time.
>
> When using git, moving the patches to a new upstream is just a rebase
> of a patched branch to a new upstream. That means if the patches are
> stored as commits those commits can be rebased and one has the changes
> and information to create the updated patches from created by the same
> resolution. Perhaps something like that is possible with bzr, too.
Well, firstly, I strongly disapprove of rebasing published branches, so
I'll mentally s/rebase/merge/g (though either is of course perfectly
possible with bzr). bzr certainly has all the pieces required to do
this (especially with looms, which share some properties with git-dpm),
although a bit of assembly would be required. Still, I've managed this
sort of thing in the recent past with git and I found that I hit
cognitive overload very quickly past about half a dozen topic branches,
even with tool assistance, so I think the 30-odd in OpenSSH would
probably make my brain melt.
As I said in my blog, I think doing this in a DVCS is almost certainly
the right answer for some point in the future, but right now I think I
would rather not be spending lots of time on experimental tools. 'quilt
pop -a && bzr merge --force' followed by repeated quilt push, resolve,
quilt refresh is distinctly suboptimal, but it at least has the virtue
of simplicity - all the bits are right out on view and it's easy to back
out if something goes wrong. With due respect to git-dpm, all the
experimental VCS tools I've seen for this right now still sort of remind
me of managing this stuff with vendor branches in CVS, which is not a
level of involvement with my tools I want to return to. :-)
Thanks,
--
Colin Watson [cjwatson@debian.org]
Reply to: