Re: problems with 3.0 format
* Benjamin Drung <bdrung@ubuntu.com> [100326 01:54]:
> as requested in the Lintian tag, here comes an email describing some
> problems with 3.0 format. I encounter the same problems like Colin
> Watson [1]. Quote:
>
> 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.
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.
> 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.
Hochachtungsvoll,
Bernhard R. Link
[1] http://git-dpm.alioth.debian.org/
[2] The biggest problem with storing the patches as commits is that
patches should not describe the history but the changes. While
this can be done in git nicely via usage of git rebase -i, git
has some problems storing[3] the history of rebased branches in the
history of some branch, so git-dpm is mostly some magic to have
the patched branch only as temporary git branch but otherwise
only as virtual branch contained in the history of some debian
branch.
[3] well, storing is possible, but only in a way hard to deal with...
Reply to: