Dealing with autotools

[martin f krafft]

also sprach Toshio Kuratomi <a.badger at gmail.com> [2009.05.09.2006 +0200]:
> 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)

you *should* though, and insist on a trust path to the author, or
else all I ever have to do to harm all Fedora people is DNS-poison
a Fedora maintainer's connection.

> 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)

Yes; or make sure that upstream understands to build the tarball
from a tag, and not the other way around: tag after the tarball was
built.

> 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.

I don't have anything to say against that, except...

>  How valuable that testing is and how the issue could be mitigated
>  via best practices are where I think discussion is valuable.

... precisely.

> (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.

Not if VCS becomes even more ubiquitous (read: even available to the
user) as it is right now.

Thanks for your valuable input!

-- 
 .''`.   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
 
dies ist eine manuell generierte email. sie beinhaltet
tippfehler und ist auch ohne großbuchstaben gültig.
-------------- 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/20090509/ee81c4fd/attachment.pgp>