William Stein <wst...@gmail.com> writes: > 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?).
Yes, here by "upstream tarball" I just meant "the tarball containing the portion of the package which is not written by us, i.e. containing the source code we need from upstream", not "the tarball provided by the upstream developers". Sorry, that was a bit confusing. Of course, in some cases our tarball of upstream stuff may be exactly the same as the official upstream tarball of their software. In that case we could either mirror it on the Sage mirrors, or just point our install scripts to its official download location. If we were modifying the official upstream tarball, though - say by removing binary blobs or whatever - then we would of course need to host this tarball on the Sage mirrors. -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
