[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

problems with 3.0 format



Hi,

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.
     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. I
        think the best answer right now is to quilt pop -a, force a
        merge despite the modified working tree, and then quilt push &&
        quilt refresh -pab until I get back to the top of the stack,
        modulo slight fiddliness when a patch disappears entirely; thus
        effectively using quilt's conflict resolution rather than bzr's.
        I suppose this will serve as additional incentive to reduce my
        patch count. I know that people have been working on making this
        work nicely with topgit, although I'm certainly not going to put
        up with the rest of git due to that; I'm happy to wait for looms
        to become usable and integrated. :-)
     3. It would be nice if there were some standard DEP-3 way to note
        that a patch has been accepted or rejected upstream, beyond just
        putting it in the description. In particular, it seems to me
        that listing patches accepted upstream could be used to speed up
        the process of merging new upstream releases.

We added some quilt rules to the eclipse package [2] to working around
problem 1.

[1] http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-03-25-thoughts-on-3.0-quilt-format.html
[2] http://git.debian.org/?p=pkg-java/eclipse.git;a=blob;f=debian/rules;hb=HEAD

-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Reply to: