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.

-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

Reply via email to