On Tue, May 15, 2012 at 8:45 PM, Jason Grout <jason-s...@creativetrax.com> wrote: > On 5/15/12 7:40 PM, Keshav Kini wrote: >> >> John H Palmieri<jhpalmier...@gmail.com> writes: >>> >>> On Monday, May 14, 2012 11:43:09 PM UTC-7, Keshav Kini wrote: >>> >>> William Stein writes: >>> > On Mon, May 14, 2012 at 12:31 AM, William Stein wrote: >>> >> On Sun, May 13, 2012 at 5:13 PM, Jeroen Demeyer wrote: >>> >>> I disagee when it comes to removing parts of a spkg. Several >>> packages >>> >>> include only partial sources. They contain the upstream tree >>> but with >>> >>> some files/directories (which Sage doesn't need) removed. I >>> think this >>> >>> is fine and should be allowed. >>> >> >>> >> Indeed. Many spkg's are full of stuff we absolutely don't want >>> to >>> > >>> > s/spkg/upstream sources (not spkg's!) >>> > >>> >> ship. They have windows binaries in them, java binaries, big >>> pdf's, >>> >> and other random stuff that wastes space and makes some people >>> >> nervous. >>> >>> OK, that's reasonable. I withdraw my objection, though it would still >>> be >>> nice if we had a better history of what is or was in the src/ >>> directories of SPKGs, if it is no longer considered possible to >>> determine this simply from the package version minus the patch >>> number. >>> >>> >>> Any changes like this are supposed to be documented in SPKG.txt, right? >>> If not, >>> the spkg needs work. >> >> >> Sure, but a blurb in SPKG.txt is not really the same as having true >> versioning of the directory. Of course, we do mostly have copies of all >> old versions of all SPKGs (going back at least as far as /home/release >> on sage.math contains versions of Sage). So we could reconstruct the >> history of these src/ directories with some effort. >> >> Note: I'm not saying we should put src/ under version control. I just >> think it's best if we modify it only at install time via patches, rather >> than at packaging time, but as Jeroen and William point out, sometimes >> it's an issue of file size, or just not wanting to include binary >> blobs... > > > It would be great if we had an spkg-prepare script alongside the > spkg-install script. The spkg-prepare script would do any packaging steps > when we did sage -spkg. That way I could just unzip a src/ file and do sage > -spkg. That would delete the things we don't want from the src/ file, etc. > Then I'd have an spkg to test. > > Or maybe it should be spkg-dist, or something.
I like spkg-dist, since it *is* spkg-dist, at least in some packages I made, such as the core sage library. -- William > > Thanks, > > Jason > > > > > -- > 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 -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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
