#9434: Stop greping for a non-existent sage-banner
------------------------+---------------------------------------------------
Reporter: drkirkby | Owner: drkirkby
Type: defect | Status: needs_review
Priority: minor | Milestone: sage-4.6
Component: build | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
------------------------+---------------------------------------------------
Comment(by leif):
Replying to [comment:20 jhpalmieri]:
> Replying to [comment:17 leif]:
> > I wouldn't call {{{sage}}} in {{{sage-upgrade}}}.
>
> I can see from your other reasons that we need to update the version
number earlier so my solution won't work, but I see no reason, a priori,
not to call {{{sage}}} in {{{sage-upgrade}}},
{{{sage-upgrade}}} isn't "the end" of the upgrade process (it's called by
{{{sage-sage}}}),
and calling the "new" Sage there can potentially cause more trouble than
we want. So since it's not necessary, I would leave it.
> after the upgrade process has completed, apparently successfully. It
actually tests further whether the upgrade succeeded.
This is done later, and finally calling the new Sage should be up to the
user, e.g. indirectly by building the documentation.
> > Rather than omitting {{{VERSION.txt}}} from the {{{sage_scripts}}}
spkg, I would put the code to update (or better: not overwrite) an
existing {{{VERSION.txt}}} in its {{{spkg-install}}}.
>
> Why? In general, copying over all *.txt files is a little dangerous,
and is part of the reason that the file sage-README-osx.txt appears in the
wrong places and isn't currently tracked in any repo.
I didn't say copy {{{*.txt}}} (otherwise checking the presence of an
existing {{{$SAGE_ROOT/VERSION.txt}}} wouldn't make much sense). But
having it there (''not'' in the repo, i.e., in {{{.hgignore}}}) we can
easily extract it before that spkg gets installed, because a new scripts
repo is always there, is relatively small and gets created by {{{sage
-sdist}}} anyway, where the new version and release date are known.
> I think if we want to include a file, it should be tracked. If it's
automatically generated, I don't see any reason to include it in a repo.
See above.
> If #9433 ever gets reviewed and merged, then all of the *.txt files in
SAGE_ROOT will be taken out of the scripts repo in any case.
Well, {{{VERSION.txt}}} shouldn't be under revision control.
> > As noted, the version file should be updated ''before''
{{{spkg/install}}} is called (and that's also before a new scripts spkg
gets installed).
>
> Right.
>
> > We'd have to extract the new version from some newly downloaded file.
(This only works for later Sage versions anyway, unless we handle it in
{{{spkg/install}}}, too.)
>
> How about extracting it from VERSION.txt?
Extracting the file from the file itself? You misunderstood me. I meant we
could extract {{{VERSION.txt}}} e.g. from the scripts repo, with
{{{tar}}}.
> I'm attaching a patch which does this, perhaps not in the optimal way,
but I think it should work.
I'll take a look at it.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9434#comment:23>
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.
