-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm trying to solicit feedback about how Quilt v3 packages should be
handled by the package importer.
First I'll start by describing my understanding of the format, so people
can correct me if I'm understanding things incorrectly.
Basically, in v3 format, you end up with
a) debian/patches/*
Individual patch files, each describing a change to the orig.tar.gz
b) .pc/
A directory managed by Quilt, which describes those patches in the
format the Quilt understands.
c) The working tree is also modified relative to the orig.tar.gz.
Eg, upstream has a file "foo" with the content "hello\n". There is a
patch which has:
hello
+world
Then there would be a debian/patches/01-add-world and some sort of
corresponding patch in .pc and the content of 'foo' in the working
tree would be "hello\nworld\n"
Some further thoughts
a) At the moment, when working on Quilt v3 format package, you need the
.pc directory around. However, there is a way to build it from
scratch if necessary.
b) Merging .patch files is a bit error prone, and certainly hard to
debug.
c) There is a whole lot of redundancy in this system. Since the
debian/patches files are somewhat replicated in the .pc directory,
which is also reflected in the state of the file contents.
d) How often is it that patches are directly layered on top of
each other (textually)? So patch 1 makes it 'hello\nworld\n' and
patch 2 changes it to "hello world\n". Or some other "patch 1 must \
be applied before patch 2 makes *any* sense"
Because if they all are textually different, then it is strictly
redundant. But otherwise it is possible for one to introduce state
that another mutates, which wouldn't be reflected in the working
state.
e) looms, still a bit of a question how this interacts with everything
else.
Now that I've described the state as I understand it, here are some
questions.
1) As I understand it, most people are in favor of *not* versioning the
.pc directory. So that when you do "bzr branch lp:ubuntu/foo" you'll
get a tree with:
a) debian/patches/* still intact
b) Those patches applied to the working tree
c) no .pc directory
2) Doesn't that mean that you have to rebuild the .pc directory right
after you get the checkout? Wouldn't it be easier to get it from the
beginning? Or is it just introducing an extra place to get conflicts
when trying to merge.
That said, if you did end up merging 2 branches that didn't have .pc
directories, how would you get the .pc directory rebuilt? (Since
presumably the patch series need to be combined in some way, and
modifications to the source tree also need to be replicated into the
patches themselves.)
All this may change again if we switch the importer to use looms, since
then you can do stuff like merge the patches one-by-one up the stack
until you get to the top, without having to deal with conflicts in .diff
format.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1MJ9UACgkQJdeBCYSNAAN1/wCgpACZF2Co2VLsD+C4QqM7Uthy
frIAn2x31OTAJhHe24Y9DlH2RtEQ4DE6
=1DAg
-----END PGP SIGNATURE-----
--
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
