Le mercredi 16 mai, William Stein a écrit:
> I'm against shipping the exact upstream tarballs with Sage, as
> explained above (e.g., what if they contain opaque Windows binaries?).

My impression is that the current situations occur (sorted in very fast
decreasing frequency) :
(1) upstream tarball is ready to ship (tarballs obtained from 'make
dist' with autotools generally belong to that category) ;
(2) upstream tarball is in fact obtained by taking a snapshot from a
repository (there something more might be needed, like running some
kind of autogen.sh, removing .hg/.svn/.git/.whatever) ;
(3) upstream tarball is a mess for various reasons.

So there is definitely a need for some script to prepare the shipped
tarball. Let me call it spkg-get-upstream-tarball for the rest.

For (1), that script could just be a one-liner wget (or is that a too
big dependency?).

For (2), that script would be a few lines to checkout and remove the
cruft. Perhaps sage could even have a generic spkg-get-upstream-from-vs
script which would be called something like :
spkg-get-upstream-from-vs --git git://url/to/upstream/foo
that would take care of doing the checkout and removing the obvious
directories ; that way each spkg-get-upstream-tarball would just call
that generic script, then do additional actions.

For (3), that script would do everything by hand.

How many (3) are there anyway?

Snark on #sagemath

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