2009/5/5 mabshoff <mabsh...@googlemail.com>: > > > > On May 5, 7:21 am, William Stein <wst...@gmail.com> wrote: >> On Tue, May 5, 2009 at 7:16 AM, <simon.k...@uni-jena.de> wrote: >> >> > Hi Michael, >> >> >> The whole point is that src contains clean upstream sources you can >> >> download from wherever you document in SPKG.txt. >> >> > OK. So what shall I do if most of the code is original, not from some >> > "upstream"? >> >> You *are* upstream. You can put an hg repo in src if you want. E.g., >> the Cython spkg has an hg repo in src/. >
I'm following this thread because it seems close to what I have been thinking about regarding eclib, which is also its own "upstream" in the sense that the particular combination of source and Makefiles in eclib exists only for inclusion in Sage. When first packaging up eclib code for Sage I did make an hg repository for it but it is redundant since I don't use hg at all outside Sage. So next time I have reason for updating th eclib spkg I may delete those .hg directories (unless Michael can come up with a reason why I should keep them). John > No, it doesn't any more since I deleted it. People hacking on Cython > can pull from the upstream repo and since the .hg repo doesn' get > installed I consider it pointless to ship it since it increases the > cython.spkg size by 4MB compared to a compressed Cython.spkg of size > 600kb or so. Except for eclib no other spkg has the sources checked in > in src and I don't think we should encourage that unless other people > are working on the code on occasion like eclib. > > Cheers, > > Michael > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
