Dealing with autotools

[martin f krafft]

also sprach James Westby <jw+debian at jameswestby.net> [2009.05.10.1523 +0200]:
> With current practices there is effectively a "Debian upstream" branch
> from the VCS, which contains thes history of the tarballs that made up
> the source packages.
> 
> Even when building from a VCS it is possible, and I would say 
> encouraged, to maintain this branch.

I've never done so, and I've never understood the need, but in the
light of the autotools discussion, it's starting to dawn on me.

Is this a separate branch with one commit per unpacked tarball, or
is this a branch which gets upstream merged and then the tarball
imported, such that the diff of that commit would effectively add
all the changes and files introduced in the act of 'make dist' or
'make tarball'?

> The above ensures that you get repeatability with the pristine-tar
> information in case you need a -2 upload, and correctly represents
> what happened in the case where there was some transformation done
> to the VCS tree to get the tarball, as this transformation will be
> in the diff between the imported tarball revision and the revision
> that it was taken from.

Good point, but I am not sure it's 100% necessary. pristine-tar is
necessary, at least in the Debian context, but whether we have its
xdiffs, or real diffs, I am not sure which to prefer. We're dealing
with auto-generated files after all. pristine-tar abuses Git for
storing the information necessary to recreate the auto-generated
files, but it's doing so in a way that is not intrusive to the user.
Asking the user to maintain a branch with auto-generated files does
not have a clear-cut benefit for me.

Am I just not seeing it?

> I am aiming to make this process very easy in bzr-builddeb, as
> I feel it should be *the* way to pull in new upstream changes.
> (Upstream has released a tarball from a tag? Use that tarball
> rather than a generated one. Upstream has no public VCS? Just
> import the tarball without the extra parent.) The above, with the
> exception of a transformation of the tarball, is all a single
> command in the latest versions.

I see your argument and the reasons for limiting the interface
between distro and upstream to release tarballs, but doesn't that
get in the way of cooperating on code and sharing patches, a benefit
of situations where upstream and packagers use the same (D)VCS?

-- 
 .''`.   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
 
the uncertainty principle:
  you can never be sure how many
  beers you had last night.
-------------- 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/20090511/0ffbe25f/attachment.pgp>