Debian Bug report logs - #572204
dpkg-dev: maintainer workflow problems with 3.0 (quilt) and VCS

version graph

Package: dpkg-dev; Maintainer for dpkg-dev is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg-dev is src:dpkg.

Reported by: Colin Watson <cjwatson@debian.org>

Date: Tue, 2 Mar 2010 11:09:01 UTC

Severity: wishlist

Found in version dpkg/1.15.5.6

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#572204; Package dpkg-dev. (Tue, 02 Mar 2010 11:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
New Bug report received and forwarded. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 02 Mar 2010 11:09:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: submit@bugs.debian.org
Subject: dpkg-dev: maintainer workflow problems with 3.0 (quilt) and VCS
Date: Tue, 2 Mar 2010 11:07:43 +0000
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                                       [cjwatson@debian.org]




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#572204; Package dpkg-dev. (Fri, 26 Mar 2010 13:12:17 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 26 Mar 2010 13:12:17 GMT) Full text and rfc822 format available.

Message #10 received at 572204@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: 572204@bugs.debian.org
Subject: 3.0 (quilt) and VCS
Date: Fri, 26 Mar 2010 14:04:52 +0100 (CET)
Hi,

I agree, dpkg-source should definitively have some “unpatch”
functionality for when people keep only the debian/ directory
in VCS, or the source in _un_patched state.

Thanks,
//mirabilos – tg@d.o
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”	(#nosec)    ‣‣‣ Please let MySQL and MariaDB finally die!




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#572204; Package dpkg-dev. (Tue, 30 Mar 2010 17:48:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 30 Mar 2010 17:48:05 GMT) Full text and rfc822 format available.

Message #15 received at 572204@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Thorsten Glaser <tg@mirbsd.de>
Cc: 572204@bugs.debian.org
Subject: Re: 3.0 (quilt) and VCS
Date: Tue, 30 Mar 2010 18:25:16 +0100
On Fri, Mar 26, 2010 at 02:04:52PM +0100, Thorsten Glaser wrote:
> I agree, dpkg-source should definitively have some “unpatch”
> functionality for when people keep only the debian/ directory
> in VCS, or the source in _un_patched state.

FWIW, this is entirely different in all respects from the workflow
described in my original bug report, and perhaps your comment should be
a separate bug with more detail.

-- 
Colin Watson                                       [cjwatson@debian.org]




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#572204; Package dpkg-dev. (Tue, 30 Mar 2010 18:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 30 Mar 2010 18:51:03 GMT) Full text and rfc822 format available.

Message #20 received at 572204@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: Colin Watson <cjwatson@debian.org>
Cc: 572204@bugs.debian.org
Subject: Re: 3.0 (quilt) and VCS
Date: Tue, 30 Mar 2010 18:25:30 +0000 (UTC)
Colin Watson dixit:

>FWIW, this is entirely different in all respects from the workflow

Mh, yes.

>described in my original bug report, and perhaps your comment should be
>a separate bug with more detail.

OK, next time I encounter this I’ll do so.

//mirabilos, who still thinks source/format=ENOENT => default=1.0
-- 
16:47⎜«mika:#grml» .oO(mira ist einfach gut....)      23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)    23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren	-- Michael Prokop über MirOS bsd4grml




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 15:54:55 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.