<html><body bgcolor="#FFFFFF"><div><br><br>On Jul 7, 2009, at 4:14, Sam Varshavchik <<a href="mailto:mrsam@courier-mta.com">mrsam@courier-mta.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><span>Richard W.M. Jones writes:</span><br><span></span><br><blockquote type="cite"><span>On Mon, Jul 06, 2009 at 11:09:51PM -0400, Braden McDaniel wrote:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>     2. improves the resiliency of the package build to changes to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>        Fedora's autotools chain.</span><br></blockquote></blockquote><blockquote type="cite"><span>Many projects come with public source repositories, and those don't</span><br></blockquote><blockquote type="cite"><span>include the binary configure/Makefile.in files.  You usually build</span><br></blockquote><blockquote type="cite"><span>those locally with a script like 'autogen.sh'.  Projects that depend</span><br></blockquote><blockquote type="cite"><span>on precise versions of the autotools are just going to break under</span><br></blockquote><blockquote type="cite"><span>those conditions.</span><br></blockquote><span></span><br><span>Bingo. Which is why this is a rather strange (not my first, or the second, or the nth choice, but I had to spend a few minutes here picking the correct adjective that expresses the general idea, but is still somewhat diplomatic) way to publish source. And, which is why this is somewhat of a rarity, and a novelty.</span><br><span></span><br><blockquote type="cite"><span>libguestfs is a case in point - the Debian maintainer builds it from</span><br></blockquote><blockquote type="cite"><span>git using some unknown version of autoconf, and I build it on RHEL and</span><br></blockquote><span></span><br><span>This is a rare exception. For each project you can cite that releases their sources this way, I'll be happy to cite twenty others who don't.</span><br><span></span><br><span>Feel free to come up with your largest list. I'll just go through Sourceforge, and grab the first x*20 projects, in response.</span><br><span></span><br><span>Given that automake's "make dist" automatically rolls Makefile.in, and configure into the tarball (together with a bunch of other stuff), one has to go out of their way to leave them out of the tarball.</span><br><span></span><br><span>Bizarre.</span><br></div></blockquote><span class="Apple-style-span" style="color: rgb(0, 35, 163);"><br></span><div><span class="Apple-style-span" style="color: rgb(0, 35, 163);"><br></span></div><div><span class="Apple-style-span" style="color: rgb(0, 35, 163);">These days distributing via tarball is bizarre.  Distributed source control is changing the way that projects work and release. Sure there are plenty of projects out here that don't work this way but more and more are headed in this direction. </span></div><div><span class="Apple-style-span" style="color: rgb(0, 35, 163);"><br></span></div><div><span class="Apple-style-span" style="color: rgb(0, 35, 163);">--</span></div><div><span class="Apple-style-span" style="color: rgb(0, 35, 163);">Jes</span></div></body></html>