William Stein <[email protected]> writes: > On Wednesday, May 16, 2012, Keshav Kini <[email protected]> wrote: >> Jason Grout <[email protected]> writes: >>> On 5/16/12 3:08 AM, Keshav Kini wrote: >>>> 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...) >>> >>> Your proposal sounds reasonable to me. In fact, it sounds really >>> nice. So if I do sage -i some-spkg, it would really download the >>> unmodified (or possibly cleaned-up) upstream source, then use the spkg >>> info that is distributed with Sage to extract, modify, and build the >>> upstream source. That's a much more traditional process, like BSD >>> ports, OSX Homebrew, etc. >> >> Yup, exactly right. It also fits in well with using Gentoo Prefix, if we >> decide to go that way, but is useful even if we don't. Especially nice >> is that it brings hacking on package install scripts into the same >> development model as hacking on $SAGE_LOCAL/bin or the Sage library, >> making it easier to consolidate Sage development into a single >> repository, a goal which I know Robert shares (which is why I presume to >> speak for him when it comes to this SPKG upstream/downstream >> partitioning idea). >> >>> the unmodified (or possibly cleaned-up) upstream source >> >> Indeed, if we went with purely unmodified upstream source (as I was >> insisting on earlier in the thread before Jeroen and William changed my >> mind), the upstream tarballs wouldn't even need to be stored on the Sage >> mirrors - we could just wget them directly from upstream. And we could >> still do that, for those packages which don't need their tarballs >> cleaned up, only patched. >> > > I'm confused: when (not if!) the website of sage or one of its components goes > down, then nobody can build Sage? How is this not a recipe for misery?
Please read again... standard packages will be 100% included within the Sage distribution tarball. -Keshav ---- Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
