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? > -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
