remove the spkg/base repo!

[jhpalmieri]

Given the creation of the Sage root repo (see #9433), the repository in SAGE_ROOT/spkg/base should be combined with it.

1. apply attachment: 11073_root_hgignore.patch to the root repo

cd $SAGE_ROOT/spkg/base
rm -rf .hg* stdint.h_Solaris9 sage-*
hg add *-install README.txt
mkdir ../bin
mv *.py sage-* *.sh text-* ../bin
cd ../bin
cp -p $SAGE_ROOT/local/bin/sage-env .
cp -p $SAGE_ROOT/local/bin/sage-spkg .
cp -p $SAGE_ROOT/local/bin/sage-sage sage
hg add . *
hg commit -m "Trac #11073: Move base repository to root repository"

4. apply attachment: 11073_root_after.patch and attachment: 11073_prereq_install.patch to the root repository.

cd $SAGE_ROOT/local/bin
hg remove sage-env sage-spkg sage-sage
hg commit -m "Trac #11073: Move various scripts to spkg/bin"

5. apply attachment: 11073_scripts.patch to the scripts repo

6. apply attachment: 11073_sagelib_misc.patch to the main Sage repo.

7. apply attachment: 11073_extcode.patch to data/extcode.

The file stdint.h_Solaris9 is not used and therefore deleted. sage-env, sage-spkg and sage-sage (renamed to sage) are moved to spkg/bin, sage-make_relative to scripts (local/bin).

The script sage-sage is renamed to spkg/bin/sage and $SAGE_ROOT is no longer put in the $PATH, such that running "sage" after sage-env will run $SAGE_ROOT/spkg/bin/sage.

Fixes #10970 (do not generate pipestatus), see also #12102 (make bzip2 a standard package) and #12206 (install sage_scripts earlier), #12311 (stop copying testcc.sh and testcxx.sh).

Dependencies: sage-4.8.alpha6

CC: @jdemeyer @kini @nexttime @williamstein

Component: build

Keywords: scripts base hg

Author: Volker Braun, Jeroen Demeyer

Reviewer: John Palmieri, William Stein

Merged: sage-5.0.beta0

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

[jdemeyer]

comment:1

I will take care of removing spkg/base/sage-check-64 in sage-4.7.alpha3.

[sagetrac-drkirkby]

comment:2

I never realised this was this duplication - it is clearly very stupid. If nothing else, copies could be replaced with links, but it would be better to do away with the repository if possible.

If the repositories can be merged, then I think that's a good idea. I don't like the idea of having a repository as a suppository of another - I think it would just add unnecessary complications. From reading about the subrepositories, I don't feel they are designed to address a need we have.

[kini]

comment:3

From what I understand of such things, using subrepositories is a huge mess. The "proper" usage case of a subrepository is basically what the src/ directory inside an spkg is - i.e. a repository that is bolted on but comes from some "upstream" place. When you commit changes to your repository, if you've modified anything in the subrepository, it automatically commits to the subrepository too (or at least tortoisehg does on windows, if I recall correctly from when I was messing with this stuff a year ago or so), allowing you to send changesets upstream with hg push or what-have-you, and when someone pulls from your repository, their mercurial pulls the latest version of its subrepository from the upstream URL rather than from your copy of it, I think. Though we sage developers have a pretty non-standard mercurial workflow - nobody ever pulls from anywhere, really - so I don't know how much this matters. Still, as drkirkby says, it would just needlessly complicate matters.

tl;dr I too support merging the repositories or getting rid of one of them over maintaining one as a subrepository of the other.

[jhpalmieri]

comment:6

Dave: in the base repository, can you explain what the files stdint.h_Solaris9, testcc.sh, and testcxx.sh are for? I know what the last two do, but are they actually used anywhere? I can't find any reference to them in SAGE_ROOT/local/bin or SAGE_ROOT/spkg. Are they called by various spkg-install files?

Right now, testcc.sh and testcxx.sh are copied (by the file spkg/install) to SAGE_ROOT/local/bin. If we're doing away with the base repository, should they be tracked in the Sage root repository or the scripts repository? Since they're scripts which might be useful in general, the scripts repo might make sense. But if they're only used in the installation process -- I don't know where they're used -- maybe the root repo makes sense. Any opinions?

[sagetrac-drkirkby]

comment:7

Replying to @jhpalmieri:

Dave: in the base repository, can you explain what the files stdint.h_Solaris9, testcc.sh, and testcxx.sh are for? I know what the last two do, but are they actually used anywhere? I can't find any reference to them in SAGE_ROOT/local/bin or SAGE_ROOT/spkg. Are they called by various spkg-install files?

I'm not aware of what stdint.h_Solaris9 was supposed to do. I think Micheal added that. It's pretty dumb, as it forces a long to be 4 bytes with:

typedef unsigned long       int_fast32_t;

which is obviously invalid on 64-bit builds. I recall having to create a ticket to stop including that file, as it was screwing up attempts to build Sage 64-bit on Solaris.

Given Solaris 10 came out in 2005, I don't think there's much point in worrying about Solaris 9 anyway.

As such, I think that stdint.h_Solaris9 should be deleted and if there is any issues it creates, we fix them. But I don't think it will create any problems.

The testcc.sh and testcxx.sh scripts are used in a few .spkg files. There's several .spkg files which have tests for the compilers, which would be much simplified if replaced by those scripts.

Right now, testcc.sh and testcxx.sh are copied (by the file spkg/install) to SAGE_ROOT/local/bin. If we're doing away with the base repository, should they be tracked in the Sage root repository or the scripts repository? Since they're scripts which might be useful in general, the scripts repo might make sense. But if they're only used in the installation process -- I don't know where they're used -- maybe the root repo makes sense. Any opinions?

I think the scrips repository will be ok. If nothing else, it is consistent with much of the rest of Sage. I don't think either of those scripts gets used before the sage-scripts package is installed, but I'm not 100% sure on that.

[jdemeyer]

comment:8

Replying to @sagetrac-drkirkby:

It's pretty dumb, as it forces a long to be 4 bytes with:

typedef unsigned long       int_fast32_t;

which is obviously invalid on 64-bit builds.

It is invalid, but not for the reason you state.

The problem is that int_fast32_t is supposed to be signed, while unsigned long is unsigned. As for size, the type int_fast32_t is required to be at least 32 bits, not exactly 32 bits, so the following would be correct, both on 32-bit and 64-bit machines:

typedef long            int_fast32_t;

In fact, on my 64-bit Linux laptop, the types int_fast16_t and int_fast32_t are typedefed to be 64-bit longs.