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