On Mon, May 9, 2011 at 1:42 PM, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote: > 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).
I suppose I was imagining checking on both ends, but that's not really necessary. - 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
