Use "tar", not "cp -pr", to copy files in spkg-install

[jhpalmieri]

According to http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.68/html_node/Limitations-of-Usual-Tools.html#Limitations-of-Usual-Tools, we should avoid the "-r" flag for cp. On linux, using "-r" or "-R" doesn't make a difference, but on OS X, the man page for cp says that with the -r flag, "it does not correctly copy special files, symbolic links, or fifo's."

As a result, after building from scratch using #6495 on OS X or OpenSolaris, the various files doc/en/reference/MODULE/conf.py, which are all supposed to by symlinks to doc/en/reference/conf_sub.py, are copies of that file instead, and the hg repo is not clean. So I'm marking this as a blocker. The only other instances of "cp -pr" in any spkg are in R spkg and in sage-make_devel_packages, neither of which causes problems, so we shouldn't worry about them.

---

Apply attachment: trac_14166-sage-tar.patch.

Component: scripts

Keywords: cp symlink OSX Solaris

Author: John Palmieri

Reviewer: Jeroen Demeyer

Merged: sage-5.8.beta2

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

[jhpalmieri]

scripts repo

[jhpalmieri]

comment:1

Attachment: trac_14166-scripts.patch.gz

[jhpalmieri]

comment:3

On Solaris, things are more complicated. If we use cp -pr, then it behaves like OS X, i.e., badly. If we use cp -pR, then it still doesn't work; instead, cp -pPR almost works. The only problem is that file permissions can get messed up, at least when a file in one directory is a link pointing to another directory. Consider this directory TEST:

$ ls -l TEST/
total 6
drwxr-xr-x   2 palmieri other          3 Feb 25 04:07 dir/
-rw-r--r--   1 palmieri other         79 Feb 24 21:13 FILE
lrwxrwxrwx   1 palmieri other          4 Feb 25 04:06 link1 -> FILE
$ ls -l TEST/dir/
total 1
lrwxrwxrwx   1 palmieri other          4 Feb 25 04:07 link2 -> FILE

Now copy it:

$ cp -pPR TEST X
$ ls -l X
total 6
drwxr-xr-x   2 palmieri other          3 Feb 25 04:07 dir/
-rwxrwxrwx   1 palmieri other         79 Feb 25 04:06 FILE*
lrwxrwxrwx   1 palmieri other          4 Feb 25 04:08 link1 -> FILE*
$ ls -l X/dir
total 1
lrwxrwxrwx   1 palmieri other          4 Feb 25 04:08 link2 -> FILE

Note the permissions on FILE. The way around this seems to be to use /usr/xpg4/bin/cp -pPR@ SOURCE TARGET, naturally.

Let's ignore the scripts patch and just focus on the patch for the Sage library.

[jhpalmieri]

Changed keywords from cp symlink to cp symlink OSX Solaris

[jhpalmieri]

Attachment: trac_14166-sage.2.patch.gz

[jhpalmieri]

Attachment: trac_14166-sage.patch.gz

Sage library

[jhpalmieri]

comment:5

There are at least two good ways to test this: start with a fresh Sage 5.8.beta1 tarball, unpack the sage library spkg (spkg/standard/sage-5.8.beta1.spkg), apply this patch, package it back up (with sage -pkg sage-5.8.beta1). Then build Sage. Or do something similar, but start with a built version of Sage. Delete devel/sage and devel/sage-main. Delete spkg/installed/sage-5.8.beta1 and anything more recent. Create a patched version of the Sage spkg, as above. Run make ptestlong.

[jdemeyer]

comment:6

Alternatively, tar is more portable than cp and usually deals with symbolic links correctly. I know for example PARI use tar during the installer for this reason. I don't know tar well enough, but something along the lines of

# tar is the most portable way to copy files
tar c * .hg* | (cd "$DEVEL/sage-main/" && tar x)

[jdemeyer]

comment:8

If you decide to stick with the current approach, please use

[ -x /usr/xpg4/bin/cp ]

instead of

[ $UNAME = "SunOS" ]

[jhpalmieri]

comment:9

I like the tar approach. Here's a patch.

[jhpalmieri]

Sage library

[jhpalmieri]

comment:10

Attachment: trac_14166-sage-tar.patch.gz

[jhpalmieri]

comment:11

With this patch, everything seems to work on sage.math, a few other linux machines on skynet, OpenSolaris (hawk), Solaris (mark), and a few OS X 10.8 boxes I have access to.

[jdemeyer]

Reviewer: Jeroen Demeyer

[jdemeyer]

Merged: sage-5.8.beta2

[jdemeyer]

comment:12

Works fine!

[jdemeyer]

comment:13

See also #14236.