On Mon, Jul 6, 2009 at 12:10 AM, Ondrej Certik<[email protected]> wrote: > On Sun, Jul 5, 2009 at 10:58 PM, kilian<[email protected]> wrote: >> >> Ondrej, >> >> On Jul 5, 6:28 pm, Ondrej Certik <[email protected]> wrote: >>> >>> Excellent, I have added you to the project, so just upload your spkg >>> package into the Downloads (hit new download and it should work). >>> >> >> OK, I uploaded it. >> >>> > One thing that I think would be great on the longer run would be to >>> > make package description files, >>> > just like the spkg files but without the src directory, and that >>> > contain the url for the upstream package. >>> > This way, people could contribute package descriptions and you could >>> > include these (small) files in >>> > the distribution. This is how the fink project (http://fink.sf.net) >>> > distributes the patches necessary to >>> > compile a variety of unix programs under OSX. >>> >>> Interesting --- so you think that SPD itself should include most of >>> those small files for most of packages and it would now how to >>> download the src directory, thus installing itself? >>> >>> I think we would have to keep it updated all the time, isn't it easier >>> to just point to the real spkg packages, that are known to work? E.g. >>> create a pool of supported spkg packages and then just do something >>> like: >>> >>> ./spd -i nose >>> >>> and it would try to download the latest spkg package. In fact, this >>> is how Sage works already (it tries to download the package form >>> sagemath.org). >> >> I thought, the advantage in having a small package description file >> would be that it would be easier to see, what the package actually >> does >> and therefore, it would be easier to monitor many packages from many >> contributors. And it would be easier to put a tree of these >> descriptions under >> source control, maybe even two trees: testing and stable. You could >> still >> keep a copy of the original source tar file as a fall-back solution. >> >> Each package description file would contain the url of the original >> source, >> its MD5 sum, a patch against this source code and maybe the email >> address >> of the package maintainer, >> >> On the other hand, the fact that the new format would deviate from the >> sage >> format would be a clear drawback. Maybe, we should have this >> discussion >> rather on the sage email list... > > Let's discuss this on the mailinglist from now on.
I would be interested in feedback of Sage developers in the above proposal. Ondrej --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
