Package: dpkg-dev
Version: 1.15.5.6
Severity: wishlist
I've been converting my packages to 3.0 (quilt) format. Firstly, let me
say that I'm very impressed; this is the first thing along the lines of
a patch system that I've actually liked, and given that I've been one of
the major monolithic-diff holdouts this is probably a sign that you've
done a good job. I think the problems outlined here are ones that any
system like this was bound to run into sooner or later.
To frame the following problems, I should say that I have been adopting
a model whereby my working tree in revision control is (a) full-source
and (b) in the patches-applied state. I have several reasons for doing
this. I use full-source revision control (as opposed to just debian/)
wherever possible because it involves minimal annoyance on checkout, and
when done properly with a distributed VCS can allow me to use normal VCS
query commands on my Debian tree and get answers which include upstream
changes. I prefer my revision control system to be in the
patches-applied state because that corresponds most closely to the tree
produced by 'dpkg-source -x', and because that means I can use '$vcs
annotate' and the like on files and see both upstream and Debian changes
in one place. I rely very heavily on annotate and log and the like, and
so this property is valuable to me; I don't want to have to correlate
patch files separately.
I haven't looked very hard at what other developers are doing with 3.0
(quilt) and revision control yet. I know that some people are working
on making patches be dynamically exported from bzr looms or topgit or
the like, and this is definitely the way I'd like to go in the future,
but it's a little beyond my experimental-VCS-technology comfort level
for the moment.
One problem with build-time patch systems was that they required users
to run funny commands at extract time. 3.0 (quilt) suffers from an
inverse problem: it requires developers to run funny commands on
checkout from a revision control system, unless you also check in the
.pc directory which strikes me as a bad idea. I've ended up putting
this fragment in several of my debian/rules files:
# You only need to run this immediately after checking out the package from
# revision control.
quilt-setup:
[ ! -d .pc ]
set -e; for patch in $$(quilt series | tac); do \
patch -p1 -R --no-backup-if-mismatch
<"debian/patches/$$patch"; \
done
quilt push -a
.PHONY: quilt-setup
I really don't want to copy and paste this into several dozen
debian/rules files, though; I use dh(1) extensively and so this can
easily triple the length of debian/rules, not to mention that this just
gets back to the old problem of whether you're supposed to run
'debian/rules patch', 'debian/rules apply-patches', 'make -f
debian/sys-build.mk apply-patches', or what-have-you.
Would it make sense to ship something in dpkg-dev that takes a "bare"
tree in 3.0 (quilt) format without the .pc directory, and converts it to
a state where you can use quilt? I'm sure it's not possible in the
general case, but as shown above there's quite a useful subset of cases
where it can be done without very much trouble.
There's a somewhat similar problem regarding upstream merges given this
VCS layout, perhaps more in the nature of a gotcha. If you do a
straight VCS merge when your tree is in the patched state, then you will
probably paint yourself into a bit of a corner. When a quilt patch is
pushed, the base file contents are stored under .pc, and effectively
changing the base contents (as one does with an upstream merge) will
confuse 'quilt refresh' if you're foolish enough to use it; and 'quilt
pop' may well fail too, so you may be stuck editing patches by hand to
get your tree sorted out.
What works much better, although to me it wasn't intuitively obvious as
it means I don't get to use my VCS' conflict resolution tools, is to
'quilt pop -a', *then* do the upstream merge (which in some VCSes may
involve forcing the merge to proceed despite uncommitted changes), then
repeatedly 'quilt push', resolve if necessary, and 'quilt refresh'.
I don't know if there's much that dpkg can do about this, but perhaps
there's room to document it somewhere so that developers without an
excruciatingly clear mental model of their VCS don't get too hopelessly
tangled up? Feel free to tell me to file a separate bug for this if
that would be better.
Thanks,
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
