search

sagemath / sage

Main repository of SageMath
https://www.sagemath.org
Other
1.34k stars 452 forks source link

Put more files under revision control. #9433

Closed jhpalmieri closed 13 years ago

jhpalmieri commented 14 years ago

Put the text files in $SAGE_ROOT, and also the text files in spkg, under revision control. (See the discussion at the end of #9351.)

Here are the instructions:

Then from $SAGE_ROOT, run the attached script attachment: 9433_hg_script.sh to create the Mercurial repository.

Testing: see http://sage.math.washington.edu/home/release/sage-4.7.alpha0/

CC: @williamstein @dandrake @kcrisman @nexttime

Component: distribution

Author: John Palmieri

Reviewer: Leif Leonhardy, Volker Braun, Jeroen Demeyer

Merged: sage-4.7.alpha0

Issue created by migration from https://trac.sagemath.org/ticket/9433

jhpalmieri commented 14 years ago
comment:43

Okay, I've fixed root-spkg-install, although I could probably just have one line

mkdir -p "$TARGET/spkg/standard"

instead of two

mkdir -p "$TARGET/spkg"
mkdir -p "$TARGET/spkg/standard"

I've also quoted every variable in sight in the scripts patch.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 14 years ago
comment:44

Okay, test -e shouldn't be a problem with bash, only (despite being POSIX) with some Solaris' /bin/sh.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 14 years ago
comment:45

You don't have to quote variable expansions in normal assignments like foo=$BAR or echos, but never mind.

Also, test -d foo is superfluous if you rm -rf foo. ("force" also implies not raising an error if the directory doesn't exist.)

I'll have to take a closer look regarding (quoting) $OPT; this might be wrong in some cases.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 14 years ago
comment:46

There are some quotes missing at the end of sage-make_devel_packages (in the newly included part.)

Quoting $OPT currently works, since it is

OPT="pPR"

but it is a bad idea to omit the dash(es) in OPT and prepend it to the expansion.

I.e., it should be

OPT="-pPR"

...

cp $OPT ... # NOT quoted

...

cp -L $OPT ... # also NOT quoted

And I'd suggest renaming OPT to CP_OPTS.

jhpalmieri commented 14 years ago
comment:47

There are some quotes missing at the end of sage-make_devel_packages (in the newly included part.)

Oops, I don't know how I missed those. Anyway, here are new versions. This changes "OPT" to "CP_OPT" and includes the hyphen.

jhpalmieri commented 14 years ago
comment:48

I'm attaching new versions of root-spkg-install and hg_script which omit the file SAGE_ROOT/sage-python. I asked about this on sage-devel and no one demanded that it be kept.

jhpalmieri commented 14 years ago

Attachment: hg_script.gz

script to initialize repository. for use by the release manager.

jhpalmieri commented 14 years ago

Attachment: root-spkg-install.gz

the file SAGE_ROOT/spkg/root-spkg-install

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 14 years ago
comment:49

Ok, except that hg_script won't work if $SAGE_ROOT contains spaces, and "sage" should be "Sage" in the messages, the patches and attached files now look fine (with the one exception below).

In my opinion more exit codes should be checked (of hg, tar and python), but most of these omissions have been in before, so it is at least "consistent". ;-) (And some tar operations are verbose, while others are not. I also think the release date should be UTC or at least contain the [time and] time zone / UTC offset.)

But sage-upgrade should in any case check that

./pipestatus "sage-spkg $ROOT_REPO 2>&1" "tee -a $SAGE_ROOT/spkg/logs/$ROOT_REPO.log"

worked before calling ./install.

I also wonder if this shouldn't (yet) be

./pipestatus "sage-spkg $ROOT_REPO 2>&1" "tee -a \"$SAGE_ROOT\"/spkg/logs/$ROOT_REPO.log"

(Not tested; the side effects of pipestatus are quite weird.)

I haven't yet applied the patches or fully checked the functionality; at least I didn't find errors in the latest attachments. :)

Btw, why aren't base packages subject to upgrading? (I would have expected the root spkg there.)

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 14 years ago
comment:50

Replying to @nexttime:

I also wonder if this shouldn't (yet) be

./pipestatus "sage-spkg $ROOT_REPO 2>&1" "tee -a \"$SAGE_ROOT\"/spkg/logs/$ROOT_REPO.log"

(Not tested; the side effects of pipestatus are quite weird.)

The above doesn't work; it should be

./pipestatus "sage-spkg $ROOT_REPO 2>&1" "tee -a $$SAGE_ROOT/spkg/logs/$ROOT_REPO.log"

(since SAGE_ROOT is in the environment anyway).

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 14 years ago
comment:51

Ouch. Forget my last comment... (i.e. the "solution") :D

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 14 years ago
comment:52

Finally :) it should be:

./pipestatus "sage-spkg $ROOT_REPO 2>&1" "tee -a '$SAGE_ROOT'/spkg/logs/$ROOT_REPO.log"
jhpalmieri commented 14 years ago
comment:53

Replying to @nexttime:

Ok, except that hg_script won't work if $SAGE_ROOT contains spaces,

Since this script only gets run once, by the release manager when this ticket is merged, and since it doesn't get distributed with Sage, I'm not going to worry about it. When Sage works with spaces in the path, if this hasn't been merged yet, I can fix it then.

and "sage" should be "Sage" in the messages,

I'll fix that. You mean messages like "Error building the sage source code package" or "Error copying sage root repository", right?

In my opinion more exit codes should be checked (of hg, tar and python), but most of these omissions have been in before, so it is at least "consistent". ;-) (And some tar operations are verbose, while others are not. I also think the release date should be UTC or at least contain the [time and] time zone / UTC offset.)

But sage-upgrade should in any case check that

./pipestatus "sage-spkg $ROOT_REPO 2>&1" "tee -a $SAGE_ROOT/spkg/logs/$ROOT_REPO.log"

worked before calling ./install.

You're right, I thought about this before, but didn't do it.

Btw, why aren't base packages subject to upgrading? (I would have expected the root spkg there.)

I'm not sure what you mean by "base packages". The sage-upgrade script will certainly upgrade the sage-root spkg. Let's see, the sage-update script will download any new spkg, including any sage-root spkg. Then it gets installed in sage-upgrade before the other spkgs, in case it changes deps or spkg/install.

Should I create an upgrade path on sage.math? I may wait a day or two for the disk situation to settle down...

Re the "pipestatus" command, I'm going to leave it as is and see what happens during testing. (When I tested a month ago or so, the sage-root spkg got upgraded, and I vaguely remember checking that the log file had the right name, but I'll test again.)

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 14 years ago
comment:54

Replying to @jhpalmieri:

Replying to @nexttime:

Ok, except that hg_script won't work if $SAGE_ROOT contains spaces,

Since this script only gets run once, by the release manager when this ticket is merged, and since it doesn't get distributed with Sage, I'm not going to worry about it.

Yes, this is (and was meant) a non-issue, I only mentioned it for completeness. ;-)

and "sage" should be "Sage" in the messages,

I'll fix that. You mean messages like "Error building the sage source code package" or "Error copying sage root repository", right?

Yes.

Btw, why aren't base packages subject to upgrading? (I would have expected the root spkg there.)

I'm not sure what you mean by "base packages".

The packages /files in spkg/base, also referred to by $(BASE) in the Makefile (deps).

The sage-upgrade script will certainly upgrade the sage-root spkg.

Yes, of course. (sage-update currently doesn't attempt to upgrade anything from spkg/base.)

Should I create an upgrade path on sage.math? I may wait a day or two for the disk situation to settle down...

I have no opinion on that.

Re the "pipestatus" command, I'm going to leave it as is and see what happens during testing. (When I tested a month ago or so, the sage-root spkg got upgraded, and I vaguely remember checking that the log file had the right name, but I'll test again.)

This again just referred to spaces in SAGE_ROOT. (My last suggestions would work with such.)

jhpalmieri commented 14 years ago

apply to scripts repo

jhpalmieri commented 14 years ago

Attachment: trac_9433-scripts.v3.patch.gz

for reference only: diff between v2 and v3 patches.

jhpalmieri commented 14 years ago
comment:55

Attachment: trac_9433-scripts.v2-to-v3.patch.gz

Here are new versions; the only difference with any content (i.e., other than capitalization, I think) is from sage-upgrade:

-./pipestatus "sage-spkg $ROOT_REPO 2>&1" "tee -a $SAGE_ROOT/spkg/logs/$ROOT_REPO.log"
+./pipestatus "sage-spkg $ROOT_REPO 2>&1" "tee -a '$SAGE_ROOT'/spkg/logs/$ROOT_REPO.log"
+
+if [ $? -ne 0 ]; then
+    echo "Error installing Sage root repository."
+    exit 1
+fi

I don't know why base packages don't get upgraded. That's for another ticket.

Should I create an upgrade path on sage.math?

I meant so that people could test "sage -upgrade". I'll do this pretty soon.

jdemeyer commented 13 years ago

Reviewer: Leif Leonhardy

jhpalmieri commented 13 years ago
comment:58

Hi Dan,

Thanks for working on this. The Sage repo patch looks good. Skimming the scripts patch, the only issue I see with the rebasing is that I think $PKGDIR should be quoted in the following (this is lines 39-41 in sage-sdist):

cp "$SAGE_ROOT"/local/bin/sage-spkg $PKGDIR/base/ 
cp "$SAGE_ROOT"/local/bin/sage-env  $PKGDIR/base/ 
cp "$SAGE_ROOT"/local/bin/sage-make_relative $PKGDIR/base/

I'll look at this more carefully when I have time.

jhpalmieri commented 13 years ago
comment:59

I also found the following corrections to be added to the part of the patch for sage-bdist:

diff -r fa7bc24587ef sage-bdist
--- a/sage-bdist    Fri Sep 24 19:13:24 2010 -0700
+++ b/sage-bdist    Fri Nov 05 14:45:36 2010 -0700
@@ -46,16 +46,15 @@
 if [ $? -ne 0 ]; then
     echo "Error copying Sage root repository."
     exit 1
+fi

 rm "$TMP"/.hg/hgrc
 echo "Done copying root repository."

-mkdir "$TMP"
-
 cd "$SAGE_ROOT"

 echo "Copying files over to tmp directory"
-cp -$CP_OPT examples local data "$TMP"/
+cp $CP_OPT examples local data "$TMP"/

 if [ -d devel/sage-main ]; then
    echo "Copying Sage library over"
@@ -63,7 +62,6 @@
    cp -L $CP_OPT devel/sagenb-main "$TMP"/devel/sagenb-main
    cp -L $CP_OPT devel/sage-main "$TMP"/devel/sage-main
    cd "$TMP"/devel
-   cd $TMP/devel
    ln -s sage-main sage
    ln -s sagenb-main sagenb
    cd sage

I'm posting a "v4" patch including this and the above change in sage-sdist (quoting "$PKGDIR").

jhpalmieri commented 13 years ago

Description changed:

--- 
+++ 
@@ -2,7 +2,7 @@

 Here are the instructions:

-- apply the patches trac_9433-sage-repo.patch and trac_9433-scripts.v3.patch
+- apply the patches trac_9433-sage-repo.2.patch and trac_9433-scripts.v4.patch
 - move the attached file "hgignore" to SAGE_ROOT/.hgignore
 - move the attached file "root-spkg-install" to SAGE_ROOT/spkg/root-spkg-install
jhpalmieri commented 13 years ago

Attachment: trac_9433-scripts.v4.patch.gz

rebased for 4.6.1.alpha0

jhpalmieri commented 13 years ago
comment:61

I'm working on providing an upgrade path (or two) for testing. I'll post here when I have links.

jhpalmieri commented 13 years ago
comment:62

Okay for testing upgrading:

./sage -upgrade http://sage.math.washington.edu/home/palmieri/misc/9433/sage-4.6.1.9433.alpha0/

This first upgrade path is just a vanilla version of 4.6.1.alpha0, plus the new root repo.

./sage -upgrade http://sage.math.washington.edu/home/palmieri/misc/9433/sage-4.6.1.9433.alpha1/

The second upgrade path contains everything from the first one, plus a change to the top-level README.txt file. This is so we can test upgrading to a plain root repo, then from there to a modified version. So upgrading to "...9433.alpha0" followed by "...9433.alpha1" should work, as well as just upgrading straight to "...9433.alpha1".

I think that if you upgrade from a version with a Sage root repo to either of these, you may be asked twice if you want to upgrade. I mentioned this issue above.

jhpalmieri commented 13 years ago
comment:63

One issue: if you upgrade a version of Sage containing "makefile", then you end up with both "makefile" and "Makefile" when you're done. We can just delete "$SAGE_ROOT/makefile" when running the root-spkg-install file. That's easy enough to do; is it the right solution?

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:64

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

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:65

Replying to @jhpalmieri:

One issue: if you upgrade a version of Sage containing "makefile", then you end up with both "makefile" and "Makefile" when you're done. We can just delete "$SAGE_ROOT/makefile" when running the root-spkg-install file. That's easy enough to do; is it the right solution?

Rename it to Makefile.old?

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:66

Replying to @jhpalmieri:

I think that if you upgrade from a version with a Sage root repo to either of these, you may be asked twice if you want to upgrade. I mentioned this issue above.

According to the comment you refer to, this should read "upgrade from a version without a Sage root repo".

jhpalmieri commented 13 years ago
comment:67

Replying to @nexttime:

We have to download spkg/install (and I'd prefer the rest, too) in sage-update (the Python script).

I'm not sure what "the rest" refers to here.

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.

Okay, I think I can do that.

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

I don't want to put it there because in a non-upgrade, it's already installed as part of the download.

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.

That's not a bad idea, but it should go on another ticket. What about the other scripts in spkg/base, for example sage-env?

Replying to @nexttime:

Replying to @jhpalmieri:

One issue: if you upgrade a version of Sage containing "makefile", then you end up with both "makefile" and "Makefile" when you're done. We can just delete "$SAGE_ROOT/makefile" when running the root-spkg-install file. That's easy enough to do; is it the right solution?

Rename it to Makefile.old?

That sounds good to me.

Replying to @nexttime:

Replying to @jhpalmieri:

I think that if you upgrade from a version with a Sage root repo to either of these, you may be asked twice if you want to upgrade. I mentioned this issue above.

According to the comment you refer to, this should read "upgrade from a version without a Sage root repo".

Yes, that's what I meant to say. Sorry for any confusion.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:68

Replying to @jhpalmieri:

Replying to @nexttime:

We have to download spkg/install (and I'd prefer the rest, too) in sage-update (the Python script).

I'm not sure what "the rest" refers to here.

Well, the files that were previously downloaded (deps and newest_version, too). But also downloading sage-env (and e.g. sage-spkg) is not a bad idea.

(I also plan to download upgrade-notes.txt and pre-upgrade-script.sh first, such that the user (and we) can make an informed choice.)

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.

Okay, I think I can do that.

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

I don't want to put it there because in a non-upgrade, it's already installed as part of the download.

Well, then hg pull would simply be a no-op. But we should check the exit codes of the commands in root-spkg-install (hg and cp) anyway.

hg incoming <source repo> returns 1 if there's nothing to pull, 0 if there are changes to pull, other values on errors, so you could change it to:

...
if [ -d "$TARGET"/.hg ]; then

    # Merge the repository, rather than overwrite changes that the
    # user may have made.
    cd "$TARGET"
    hg ci  # Don't know if we should check in unconditionally,
           # so perhaps move this below the if-elif-fi.
    # should check for errors here

    hg incoming "$CUR"  # perhaps redirect output
    if [ $? -eq 1 ]; then
        # No changes to pull
        exit 0
    elif [ $? -ne 0 ]; then
        # Some error, report...
        exit 1
    fi
    # $? = 0: Changes to pull...
    hg pull "$CUR"
    hg merge tip
    hg ci -m "Check-in during upgrade of Sage."
    hg update
    # Add error checks above, too.

else
    ...

(Or you could add a rule to deps that tests its presence / the need to pull first, before calling sage-spkg. But if we one day generate deps, this would be less optimal.)

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.

That's not a bad idea, but it should go on another ticket. What about the other scripts in spkg/base, for example sage-env?

Yes, see above. Once we have this ticket in, it will be easier (or at least safer) to make such changes. :-)

P.S.: I wonder if the presence of $SAGE_ROOT/.hg guarantees us a functional Mercurial... ;-)

jhpalmieri commented 13 years ago
comment:69

Replying to @nexttime:

Downloading these various files in sage-update seems to at least partly defeat the purpose of the new repo, but anyway.

Replying to @jhpalmieri:

I don't want to put it [deps] because in a non-upgrade, it's already installed as part of the download.

Well, then hg pull would simply be a no-op. But we should check the exit codes of the commands in root-spkg-install (hg and cp) anyway.

If we put it in deps, I guess it gets installed at the end? I was tempted to make it part of BASE, but then during an upgrade, any changes to the Sage root repo would mean that everything would be rebuilt, which would be annoying. The only issue is if there is an upgrade to a script like "pipestatus" which is in the root repo, is used in the upgrade process, and is not downloaded in sage-update.

P.S.: I wonder if the presence of $SAGE_ROOT/.hg guarantees us a functional Mercurial... ;-)

I think I'll switch to running "hg verify".

jhpalmieri commented 13 years ago

Description changed:

--- 
+++ 
@@ -4,7 +4,20 @@

 - apply the patches trac_9433-sage-repo.2.patch and trac_9433-scripts.v4.patch
 - move the attached file "hgignore" to SAGE_ROOT/.hgignore
-- move the attached file "root-spkg-install" to SAGE_ROOT/spkg/root-spkg-install
+- move the attached file "root-spkg-install.v2" to SAGE_ROOT/spkg/root-spkg-install
+- move the attached file "install" to SAGE_ROOT/spkg/install
+- move the attached file "deps" to SAGE_ROOT/spkg/standard/deps

 Then **from $SAGE_ROOT**, run the attached script "hg_script" to create the Mercurial repository.

+To test upgrading, try
+
+```
+./sage -upgrade http://sage.math.washington.edu/home/palmieri/misc/9433/sage-4.6.1.9433.alpha0/
+```
+You can then try
+
+```
+./sage -upgrade http://sage.math.washington.edu/home/palmieri/misc/9433/sage-4.6.1.9433.alpha1/
+```
+to test an ugrade which changes an existing root repo: it is supposed to upgrade without error, changing just the beginning of the file SAGE_ROOT/README.txt.
jhpalmieri commented 13 years ago
comment:70

Okay, here's a new scripts patch (with no changes to sage-update or sage-upgrade), along with new "deps" and "install". I've updated the upgrade paths I listed above; I'm adding them to the ticket description. I am still building Sage 4.4; when that's done, I'll test upgrading it.

jhpalmieri commented 13 years ago

Description changed:

--- 
+++ 
@@ -20,4 +20,4 @@

./sage -upgrade http://sage.math.washington.edu/home/palmieri/misc/9433/sage-4.6.1.9433.alpha1/

-to test an ugrade which changes an existing root repo: it is supposed to upgrade without error, changing just the beginning of the file SAGE_ROOT/README.txt.
+to test an upgrade which changes an existing root repo: it is supposed to upgrade without error, changing just the beginning of the file SAGE_ROOT/README.txt.
jhpalmieri commented 13 years ago

the file SAGE_ROOT/spkg/install

jhpalmieri commented 13 years ago

Attachment: install.gz

Attachment: install.patch.gz

diff between current install and new one; for reference only

jhpalmieri commented 13 years ago

Attachment: root-spkg-install.v2.gz

the file SAGE_ROOT/spkg/root-spkg-install

jhpalmieri commented 13 years ago

Attachment: trac_9433-scripts.v5.patch.gz

patch for scripts repo

jhpalmieri commented 13 years ago

Description changed:

--- 
+++ 
@@ -2,7 +2,7 @@

 Here are the instructions:

-- apply the patches trac_9433-sage-repo.2.patch and trac_9433-scripts.v4.patch
+- apply the patches trac_9433-sage-repo.2.patch and trac_9433-scripts.v5.patch
 - move the attached file "hgignore" to SAGE_ROOT/.hgignore
 - move the attached file "root-spkg-install.v2" to SAGE_ROOT/spkg/root-spkg-install
 - move the attached file "install" to SAGE_ROOT/spkg/install
jhpalmieri commented 13 years ago

the file SAGE_ROOT/spkg/standard/deps

jhpalmieri commented 13 years ago

Attachment: deps.gz

diff between current deps and new one; for reference only

jhpalmieri commented 13 years ago
comment:73

Attachment: deps.patch.gz

For what it's worth, I've done the following successfully with the current versions:

This was all on sage.math. I also tested 4.6.1.alpha0 on OS X 10.6 with no problems.

I'm testing "./sage -bdist ...", which I forgot to do earlier. I'm also testing a build from scratch on another platform.

jdemeyer commented 13 years ago
comment:74

Is this ticket now really ready for review? (if not, please change status to needs_work).

jdemeyer commented 13 years ago
comment:75

Please also add a root-spkg-install.patch. I prefer using the patches, not the patched files.

jdemeyer commented 13 years ago
comment:76

Can the people involved in this ticket give their opinion about #10231? (informally, the patch is not yet ready for review) If you agree with #10231, we need to coordinate this ticket with it.

jhpalmieri commented 13 years ago
comment:77

Replying to @jdemeyer:

Please also add a root-spkg-install.patch. I prefer using the patches, not the patched files.

I'm not sure what you mean: the file "root-spkg-install" is completely new to this ticket, and is not part of any pre-existing repo. So there's nothing to patch. I'm flipping this back to "needs review".

Regarding #10231, I'd like to see more discussion on sage-devel about it. I know that leif disagrees, but I'm also interested in the idea of combining the various non-root repos (scripts, examples, extcode, and the main Sage library) into one. It seems like the Sage community should decide about both of these issues in sage-devel rather than on a trac ticket.

jdemeyer commented 13 years ago

Description changed:

--- 
+++ 
@@ -3,8 +3,8 @@
 Here are the instructions:

 - apply the patches trac_9433-sage-repo.2.patch and trac_9433-scripts.v5.patch
-- move the attached file "hgignore" to SAGE_ROOT/.hgignore
-- move the attached file "root-spkg-install.v2" to SAGE_ROOT/spkg/root-spkg-install
+- move the attached file "hgignore" to SAGE_ROOT/.hgignore (note that this is a *new* file)
+- move the attached file "root-spkg-install.v2" to SAGE_ROOT/spkg/root-spkg-install (note that this is a *new* file)
 - move the attached file "install" to SAGE_ROOT/spkg/install
 - move the attached file "deps" to SAGE_ROOT/spkg/standard/deps
jdemeyer commented 13 years ago
comment:78

Replying to @jhpalmieri:

Replying to @jdemeyer:

Please also add a root-spkg-install.patch. I prefer using the patches, not the patched files.

I'm not sure what you mean: the file "root-spkg-install" is completely new to this ticket, and is not part of any pre-existing repo.

In that case, sorry for the noise.

jdemeyer commented 13 years ago
comment:79

Replying to @jhpalmieri:

Regarding #10231, I'd like to see more discussion on sage-devel about it. I know that leif disagrees, but I'm also interested in the idea of combining the various non-root repos (scripts, examples, extcode, and the main Sage library) into one. It seems like the Sage community should decide about both of these issues in sage-devel rather than on a trac ticket.

Well, there was some discussion at http://groups.google.com/group/sage-devel/browse_thread/thread/cc30eaf87b283881/c2290991827fec9c?hl=en_US&#c2290991827fec9c.

Personally, I simply don't see the need for merging sage, sage_scripts, extcode, examples,... into one big spkg. So there is some disagreement on this. But this disagreement should not stop us from doing something to which most people seemed to agree: not repackaging extcode and examples with every new Sage version (which is exactly what I want to accomplish with #10231).

jhpalmieri commented 13 years ago
comment:80

Replying to @jdemeyer:

Well, there was some discussion at http://groups.google.com/group/sage-devel/browse_thread/thread/cc30eaf87b283881/c2290991827fec9c?hl=en_US&#c2290991827fec9c.

Not too much discussion of that proposal. You suggested it, and a few people liked the idea. On the other hand, a few people made the counter-proposal to merge all of the repositories. If we end up merging everything, then doing #10231 first will make more work: whatever is involved in that, and then the merge, as opposed to just the merge. So I'd like to see more of a consensus about which direction to go before putting much effort into #10231.

This ticket seems like a separate issue, and regardless of everything else, the Sage root repo should remain separate from the others, because it should already be installed when you unpack the Sage tar ball. Perhaps its role should increase, including files like sage-env and sage-spkg, but that's for another ticket. I hope this ticket can get a positive review soon, and then if anyone feels like working on #10231 (or on a possible merge of the repos), they can base their work on this ticket and other tickets which touch sage-sdist and related files.