William Stein <wst...@gmail.com> writes: > On Wed, May 16, 2012 at 3:50 AM, Keshav Kini <keshav.k...@gmail.com> wrote: >> William Stein <wst...@gmail.com> writes: >>> On Wed, May 16, 2012 at 2:35 AM, Robert Bradshaw >>> <rober...@math.washington.edu> wrote: >>>> I don't think we should be storing the unpacked src/ directory in the >>>> spkg at all, instead we should store a pointer to a tarball (which >>>> could be external or right in the spkg itself. Upon install this >>>> tarball would get unpacked into src/. The sage-spkg script would >>>> unpack this tarball, compare it to src/ (if it exists) making sure >>>> there are no differences (that are not accounted for by the existing >>>> patches, or perhaps even creating a patch to describe the difference), >>>> and then create the .spkg file excluding the src/ directory (but >>>> possibly including the pristine, unpacked tarball). >>> >>> I read the above 4 times and I don't understand what you're proposing, >>> except maybe (?) to make it impossible to build Sage if you're not >>> connected to the internet...? Or to basically change nothing? >>> Confused. >> >> This would make it possible to ship spkg-install scripts and SPKG.txt >> files for all optional and experimental SPKGs at a low disk space cost >> (because their src/ dirs would not be shipped). Integrating this stuff, >> along with everything else, into a single repository, would allow for >> easier development. This goes back to what we discussed at Review Days >> 2. > > This = what? Clearly you claim to understand what Robert is > proposing. I don't even know what "this" is.
Currently: The package named foo consists of one file called foo-x.y.z.pn.spkg. It is a tarball containing some files and directories (such as spkg-install and patches/), among which is a directory called src/. Stuff other than src/ is under revision control in the root directory inside the tarball, and consists of stuff written by Sage developers. src/, on the other hand, is not under revision control, and consists of stuff written by upstream developers. If the package is a standard package, the .spkg file is shipped with Sage. If it is optional or experimental, it is stored on the Sage mirrors and can be downloaded and installed by users with `sage -i`. What I am proposing (and I guess it's similar to what Robert was saying): The package named foo consists of some files and directories created by Sage developers, and some files created by upstream developers. The files and directories created by Sage developers are shipped as part of Sage - not in a tarball, just in the file tree. The files created by upstream developers sit in a tarball. That tarball can be shipped with Sage, or not. The foo-related files created by Sage developers and shipped in the Sage tree include a datum which gives a location of the upstream tarball, either as a path in the Sage file tree, or as a URL for an external downloadable file. If the package is a standard package, the upstream tarball is shipped with Sage. If it is optional or experimental, it is stored on the Sage mirrors. Either way, the spkg-install, patches/, etc. created by Sage developers are shipped with Sage, and know where to find the corresponding upstream tarball, whether locally or remotely. (Hopefully that was easier and not harder to understand than what Robert said, but I'm not convinced it is...) -Keshav ---- Join us in #sagemath on irc.freenode.net ! -- 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
