On Thu, 2008-10-09 at 13:37 -0700, Jesse Keating wrote: > On Thu, 2008-10-09 at 22:26 +0200, Till Maas wrote: > > On Thu October 9 2008, Jesse Keating wrote: > > > On Thu, 2008-10-09 at 18:16 +0200, Till Maas wrote: > > > > On Thu October 9 2008, Jesse Keating wrote: > > > > > Only if we allow source repo tags to be a suitable source distribution > > > > > method. Since fedorahosted still doesn't have an easy to use way of > > > > > distributing tarballs, and getting the code via a scm checkout is quite > > > > > easy, it should suffice. > > > > > > > > If this is the only obstacle to get this done, I will write a patch for > > > > Makefile.common that displays the URL for every file in sources to fetch > > > > it from the lookaside cache. Then this URL can be provided as source > > > > tarball on a fedorahosted wiki page. > > > > > > Why must we insist on tarballs? Unless the tarball includes scm > > > metadata in it, it's practically useless for upstream patch development. > > > > Tarballs allow to easily build the desired software via rpm and test it. With > > make patch and make rediff and make prep from Makefile.common it is also > > pretty easy to create and update patches. I have sucessfully created patches > > for upstream using this. Using directly an upstream scm, it is always a PITA > > to make the spec build from there, because the spec needs to be heavily > > modificated or I have to remember to recreate the tarball everytime. It would > > like it very much, if this would be a lot easier, e.g. some intelligent > > macros in spec files that allow to use a scm instead of a tarball to be used > > as Source0 and some magic that allows to define what from the scm should be > > used, e.g. should uncommited changes be used? > > > > Nevertheless, there have to be tarballs in the cvs lookaside cache, therefore > > it is not much work to link to them. Therefore I do not really see what needs > > to be discussed here. ;-) > > I'm trying to see things from somebody else's point of view. Recently, > on this list, somebody else was arguing that we in Fedora land should be > doing away with tarball distribution, and srpm distribution, and instead > direct everything back to SCM, and to work on RPM so that it just > understood SCM and left tarballs in the past. Thank you for providing > some argument against that (: There are many more arguments against directly working from an SCM: + tarballs are easy to verify, long-term stable and easy to copy. + tarballs don't need a server infrastructure. + tarballs need a minimal client infrastructure. + tarballs decouple "rpms" from "upstreams". That said, I find letting rpm directly work from SCMs to be - unstable/unreliable - unsafe/a security risk - resource demanding - adding too many project dependencies. => I actually hardly find an argument speaking for letting rpm work directly from an SCM. Ralf -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
