Debian packaging with git and conflicts resolution

[martin f krafft]

also sprach Stefano Zacchiroli <zack at debian.org> [2008.11.30.1832 +0000]:
> Now, assuming there is a sane way of storing the information
> needed to address both targets, what about providing patches for
> both targets?

The only sane way I see is by dumping the DAG itself in a way that
would allow it to be imported into a DVCS and processed from there.
I have not found a viable way to actually do this.

> However, this can open a can of worms, because it implicitly
> assumes that single patches are picked from the patch set. If more
> than one patches are desired, conflicts between them will be need
> to be solved by the picker.

One way would be to store topic patches and recorded conflict
resolution, but I know of no way to do that, especially no portable
way. Also, conflict resolution would have to be created and stored
for each permutation of topic branches, which is surely asking a bit
too much, given that this cannot be automated.

I like the thought of providing debian/patches as a series of
changes, primarily useful for people to research differences between
upstream and my package, and as useful references in discussions
with upstream.

For instance, when I raised a bug with Postfix and IPv6[0] on the
postfix-users mailing list, I was able to point out that Debian does
not modify the IPv6 code at all by pointing at
http://patches.debian.net[1], knowing that those patches are
actually applied during the Debian build.

0. Title "permit_mx_backup_networks does not accept IPv6 addresses"
   against postfix, I am offline, so I cannot provide a number.
   Submitted with <20080915152759.GA8083 at lapse.rw.madduck.net>.
1. <20080915153238.GB8114 at lapse.rw.madduck.net>

In the postfix case, it didn't really matter that a given patch
D only applies to postfix in the context of patches A,B,C because
the consumer (a human, or group of humans) are more intelligent than
/usr/bin/patch and could extract the necessary information without
troubles.

On the other hand, if you combine features on the integration branch
and export them to debian/topics as well, there is no guarantee that
the sets of branches integrated is equivalent to the set of branches
exported.

In addition, the patch series allows me to distribute upstream and
Debian's modifications separately from each other, without mashing
them together into a monolithic diff.

I think this is the use-case I want to support, and that anyone who
is actually interested in one of my features independently of the
others should use the VCS directly.

There is of course the argument of the person working wanting to
work with my code without connectivity, and I don't want to discard
that. However, this person *can* get the feature branch from the
series. In the rare (?) case that the feature overlaps with another,
then s/he will have to work a bit more, e.g. applying A..D and then
reverse-applying C..A, while resolving conflicts in favour of D.
I don't think that's too much to ask.

In the end, I am primarily packaging, not primarily distributing
source code. Thus I want my tools and workflows geared at that, not
to try to jump through hoops to build a package from a bundle that's
more optimised for distribution of the source and modifications.

-- 
 .''`.   martin f. krafft <madduck at d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"arrogance on the part of the meritorious is even more
 offensive to us than the arrogance of those without merit:
 for merit itself is offensive."
                                              -- friedrich nietzsche
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20081201/19ff554d/attachment.pgp