On Wed, May 16, 2012 at 5:41 AM, Keshav Kini <keshav.k...@gmail.com> wrote: > William Stein <wst...@gmail.com> writes: >> On Wednesday, May 16, 2012, Keshav Kini <keshav.k...@gmail.com> wrote: >>> Jason Grout <jason-s...@creativetrax.com> 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.
Sorry, I read it in a bumpy cab. You wrote "If the package is a standard package, the upstream tarball is shipped with Sage". By this do you really mean "If the package is a standard package, then a modified version of the upstream tarball is shipped with Sage"? I'm against shipping the exact upstream tarballs with Sage, as explained above (e.g., what if they contain opaque Windows binaries?). -- William > > -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 -- 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
