#9433: Put more files under revision control.
------------------------------+---------------------------------------------
Reporter: jhpalmieri | Owner: tbd
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-4.6.1
Component: distribution | Keywords:
Author: John Palmieri | Upstream: N/A
Reviewer: Leif Leonhardy | Merged:
Work_issues: |
------------------------------+---------------------------------------------
Comment(by leif):
Hmmm, this doesn't work for upgrades from older versions (<=4.5), and as
you mentioned, behaves strange on newer versions >=4.5.1.
We '''have to''' download `spkg/install` (and I'd prefer the rest, too) in
`sage-update` (the Python script).
What's currently newly made in `sage-upgrade` should be moved to that
file, which is in any case the fresh, downloaded one. ''There'' we have to
make a distinction on if we are upgrading.
If so, `spkg/install` should then install the root repo (preferably
without overwriting itself, but the root repo should, i.e. must, contain
exactly the same file), since our "real" Makefile `spkg/standard/deps`
doesn't (though I don't know why you don't want to put the root spkg
there).
Btw, it would be better to also have `sage-spkg` in the root rather than
the scripts repo; or download an identical copy (from the scripts repo)
along with `install`, `deps` etc.
This way we would always do the whole build with the new one, and not
switch the version during the installation (after the new scripts spkg has
been installed).
Another reason to keep the repos separate, and not as Robert B. suggested
on sage-devel, merge them all into an even larger, monolithic one.
(To avoid trouble with getting overwritten, a script can always clone
itself and then `exec` this copy, passing it a parameter such that it
knows if it's the clone or the original, similar to `fork()`. We should
IMHO do this for a few scripts involved in upgrading and the build
process. Therefore, the chain or stack of called rather than `exec`'ed
scripts shouldn't be deep.)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9433#comment:64>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
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-trac?hl=en.
