On 2011-05-09 18:01, Robert Bradshaw wrote: > On Sun, May 8, 2011 at 4:43 AM, David Kirkby <drkir...@gmail.com> wrote: >> On 8 May 2011 05:37, Robert Bradshaw <rober...@math.washington.edu> wrote: >>> On Sat, May 7, 2011 at 6:45 AM, David Kirkby <drkir...@gmail.com> wrote: >>>> On 7 May 2011 10:59, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote: >>>>> On 2011-05-06 19:53, Robert Bradshaw wrote: >>>>>> Even better would be to checksum the source in a src.md5 file, and >>>>>> have sage -spgk warn/error if the checksums don't match. >>>>> I think it is necessary and sufficient to checksum the output of "ls -lR". >>>> >>>> I would not rely on that, as a different UID or GID on different >>>> systems will give different results. >>> >>> As would touching a file (e.g. to revert a patch or accidental >>> change), or any change keeping the length of the file the same (yes, >>> small patches do that sometimes). >> >> You raise an interesting point. My solution with cksum would not >> detect if the file has been touched whilst the contents remain the >> same, since its only checking the contents, not the date. >> >> But if someone has touched a file, but did not change the contents, it >> is not really an issue. > > That was my point, +1 to chksumming the files, not the listing. > Preserving dates is nice, but that will make it much harder to work on > files (e.g. if I patch a file to test something out, then I'd have to > touch it back to the old time, if I can even remember that, or > re-unpack the sources. If Makefiles are an issue, one can touch the > entire directory to have the same timestamp. > >>>> MD5 would not be good, as different systems have either no program to >>>> compute an md5 checksum, or have them with different names. Although >>>> many systems have a "sum" command, the algorithm will be system >>>> dependant, so that too can't be used. >>>> >>>> In contrast, POSIX defines "cksum" so using that as a checksum tool is >>>> preferable. >>> >>> cksum is cryptographically weak, but strong enough for this purpose. >> >> Yes, there's a small probability of failure - I think 1 in 2^32, >> though perhaps thatś not true. It was not designed for cryptographic >> purposes, but for just the sort of application being discussed here. > > I brought up the issue because someone mentioned signatures. > >> I suspect md5 is more computationally intensive, but the real problem >> with md5 is there is no single command which will work on every >> system. > > Although finding that single command can be bothersome--with shell > scripting there are a whole lot of commands that worn on one (or even > most) posix systems and not on all of them, or even in one shell and > not another, as evidenced by the amount of work spent porting the <1MB > shell scripts we have to Solaris. WIth Python, if it works on my > system it has a 99.9% chance of working on yours, and > version-to-version changes, though non-trivial, are small (e.g. Cython > runs with 2.3 through 2.7 on a single codebase). 3.x excluded, but > that was 5+ years of backwards incompatible changes all pushed at > once. And of course in Sage we end up using/interfacing with a lot of > C libraries, which are not so portable. > > That being said, our hands are tied as Python is not a prerequisite > for building that first spkg. What do you mean? The procedure we are discussing has nothing to do with *building* a spkg, it has to do with *creating* a spkg (sage -spkg).
> > - Robert > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
