martin f krafft wrote: > also sprach Toshio Kuratomi <a.bad...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss