On 15 Nov., 20:29, William Stein <wst...@gmail.com> wrote: > On Tue, Nov 15, 2011 at 11:13 AM, Bill Janssen <bill.jans...@gmail.com> wrote: > > I'm a bit unclear as to why third-party source packages are unpacked > > in an spkg? Since the patching protocol is very strict, would it make > > sense for me to include Imaging-1.1.7.tar in the "src" directory of > > the spkg, instead of unpacking it into raw files? > > Please don't do that, if for no other reason than that there are over > 100 packages that don't do that, and over 100 people who are used to > having src by the extracted upstream source. > > We could have included a tarball version of the src directory in > spkg's, but that just slows down development (one has to go through an > extra step to look at it every time) and complicates things, and it > doesn't actually prove anything about the contents actually being > correct. Also, often upstream tarballs are full of crap (e.g., > windows binaries, pdf's that are huge and useless, etc.) that have to > be deleted. > > -- William > > -- > William Stein > Professor of Mathematics > University of Washingtonhttp://wstein.org
Hi, there is another reason: "tar" is not necessarily equal to "tar". The Sage build scripts try to use only the most generic options, and provenly work on the supported number of systems. If you provide some file tarred upstream, then this might not be "out-of-the-box" readable by the system tar on some of the supported platforms (think of e.g. Solaris). Sage could bring its own tar with it to circumvent this problem, but up to now, there was no real need for that. Cheers, Georg -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
