also sprach Toshio Kuratomi <a.bad...@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 <madd...@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.
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss