On Sun, Jul 5, 2009 at 10:58 PM, kilian<koeps...@gmail.com> wrote: > > Ondrej, > > On Jul 5, 6:28 pm, Ondrej Certik <ond...@certik.cz> 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. Ondrej --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
