Dealing with autotools

[Toshio Kuratomi]

martin f krafft wrote:
> also sprach Toshio Kuratomi <a.badger at gmail.com> [2009.05.09.1842 +0200]:
>> There are advantages to using tarballs.  Whether they outweigh the
>> convenience of building directly from VCS is certainly up for
>> debate (and has been debated many times on Fedora devel list,
>> among other places ;-)
> 
> Pointers always welcome. ;)
> 
heh.  My lack of enthusiasm for trawling through the old threads is
precisely why I try to remember the reasons that made sense and never go
back there :-)

>> One of the reasons I remember as actually having validity was that
>> tarballs have a large test base vs an SCM snapshot.  (Even if you
>> build from a tag, you have to depend on upstream having tagged the
>> correct version that actually got into the tarball).
> 
> Isn't this something the maintainer could quickly check?
> 
Not nearly as quickly or as easily as verifying that the tarball is
pristine.  The process for verifying the tarball is:

1) Is source url canonical?
2) Download tarball from source url.
3) sha1sum tarball just downloaded matches with sha1sum tarball used to
build package.

(If you're the maintainer, you don't have to do step 3)

If you're verifying that a SCM tag matches the rleased tarball, you
start at step #3 and add the following steps:

4) Pull the latest source from the repo
5) untar the tarball
6) Diff between the source repo and the tarball
7) For the differences between the source repo and tarball check that:
  * the differences are due to a file generated in the creation of the
tarball (like configure or Makefile.in)
  * files that won't matter to the build (upstream has a HOW_TO_RELEASE
file in the repo that isn't in the tarball)
  * other things that are more subtle :-(  (permissions on files,
versions substituted into files at tarball creation time, etc)

> Also, are you sure of the large test base? The most important
> package I maintain is mdadm, and I don't know a single person who
> uses it directly, other than through Doug's or my packages. I admit
> I don't know any !(Fedora||Debian*) users though, except for
> upstream himself, who uses OpenSuse.
> 
> mdadm ist Linux-only, the whole picture changes when you think about
> something like postfix. However, do you think that those folks who
> rebuild their software for every upstream release are really going
> to be a better test base than a new postfix package with 10 days to
> survive in Debian unstable (or the same concept for other distros)?
> 
Yes.  One of your assumptions is wrong.  You limit the other people to
"those folks who rebuild their software for every upstream release".  In
fact, distributions are not going to all switch to a snapshot model
immediately (some may not do so until upstreams stop releasing
tarballs.)  So you could have the set of Debian and Ubuntu users using a
snapshot while Fedora, Red Hat, Gentoo, NetBSD, Freebsd, MacOS-fink,
Solaris, OpenSuSE, (et al) using the tarball.

Even if we get a significant portion of distros basing off of snapshots
instead of release tarballs, we still have the problem of which snapshot
is being used.  It's nice to assume that people will only use a tag
representing a release but I doubt that that's what will happen in
practice.  Working with upstream's repository directly makes it easy to
base your package against something slightly newer than the release that
just picks up this one tiny bugfix and oh, this other small feature, and...

So yes, I think the base of testing of a single tarball now is much
higher than what we'll see collectively even if we all go to snapshots.
 How valuable that testing is and how the issue could be mitigated via
best practices are where I think discussion is valuable.

(Note, that abandoning tarballs also starts to impact users as well.  In
a vanilla tarball scenario it's easy to see what the distro specific
changes to an upstream release are.  In a snapshot scenario, the base
from which you're working can be different as well.  This makes it
harder for upstream and the user to work together as they don't have a
common understanding of what they're running.  A user can quickly verify
whether there are local patches to an upstream tarball.  They will have
more difficulty figuring out whether the snapshot included in the
package is exactly equivalent to upstream's release or has changes in a
relevant area.)

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20090509/6302e575/attachment.pgp>