> The other problem is that so much isn't under revision control (eg. > what versions of spkgs to use), or in multiple repositories that need > to be kept in sync. Were I to design the system from scratch, I'd put > all our code (devel/scripts/...) in a single repo, along with the > top-level files, and a list of dependencies (spkgs).
Are you thinking about something like this, a file, say singular-version which points to the current Singular version? Applying a patch which changes this textfile implies updating the Singular SPKG? Then, patches can depend on other patches in a clean way? > Building sage > would fetch (locally or remotely) the dependencies listed and build > them in such a way that changing the list of dependencies and > re-building would easily and cheaply reversible. I would probably > still build my own Python, but may require it (flexible version) as a > bootstrapping prerequisite. Whether the non-upstream parts of an spkg > belong in the spkgs or the main repo, I'm not sure, but I'd rather > *everything* be expressed as commit to a single repository (possibly > moving a pointer to some new, vanilla upstream source, rather than > putting all upstream sources in our repo). > > If others have similar views, maybe we could move in that direction. +1 Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://martinralbrecht.wordpress.com/ _jab: martinralbre...@jabber.ccc.de -- 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
