On 31 March 2010 01:57, William Stein <wst...@gmail.com> wrote: > On Tue, Mar 30, 2010 at 4:33 PM, Dr. David Kirkby
>> Could it be a forward compatibility issue? >> >> 1) Sage 4.3.4 contains the latest iconv (1.13.1) >> >> 2) Code is Sage tests iconv, finds it's a late version, and makes use of the >> features in the the latest version. >> >> 3) After doing a 'sage -upgrade', iconv 1.13.1 is removed. >> >> 4) After 'sage -upgrade' the system supplied iconv is the only iconv package >> available. Any code which relied on new features in the latest iconv library >> suddenly breaks, as those features no longer exist. >> >> Note, the iconv package I created deletes old copies of itself, as >> spkg-install contains: > > Yes, I'm sure this is the problem. I only postulated this. I'm certainly not sure it is the reason, though I suspect quite strong it is. > Thus your iconv package in > sage-4.3.5 will *break* most sage's version <= 4.3.4 that upgrade... No it will not. It will only be version 4.3.4, as that is the only version which will have installed iconv. The iconv package never existed in earlier releases. > Can you make a version of the spkg that doesn't delete the previous > version on operating systems where iconv isn't going to be installed? > I.e., make an spkg asap that tests if not on solaris or cygwin, and in > that case immediately exits. This test should be first, before > anything else. > > I can then post that spkg online, so "sage -upgrade" isn't broken. > > -- William I can do that, but it will have to wait until the weekend, as I am tied up and are not at home. I don't have time to create the revised spkg and test it. I believe this incident highlights a number of issues I've raised before, but sometimes I feel I'm hitting my head against a wall. 1) Firstly R get's updated without testing on Solaris, so it broke Sage 4.3.3 on Solaris, because the latest R needs iconv. This shows a lack of testing to me. (See also point 5 below). 2) The fact R's configure script indicated the option to disable iconv was not a valid option was ignored. 3) Iconv had to be hurriedly put into Sage as a standard package (bypassing optional) in order for Sage to build on Solaris again. With adequate testing of R, this would not have been necessary. 4) Having a global iconv and one in Sage caused problems on some linux distributions. One of the libtool developers has told me this is a fundamentally flawed method. He was not surprised when there was a similar issue with another library, with the linker reporting two copies of the same library. I must admit, I thought LD_LIBRARY_PATH would take care of that, but it is clear that multiple copies of the header files will be included when building iconv - or any other library for that matter. I don't know a totally satisfactory solution to this, but I believe the current method does have a fundamental flaw. When one of the main libtool developers tells me it is flawed, and he is not surprised we get problems, I tend to worry. 5) The new iconv package I created was merged into Sage 4.3.4, without it being fully tested. I personally confirmed it worked on sage.math (Linux - I don't know what distribution), bsd.math (OS X), t2.math (latest Solaris 10 release) and one of my own Solaris machines (first Solaris 10 release). But the iconv package was *not* tested on all supported platforms before a release was made. To me, the release system is fundamentally flawed. I believe the release managers should wait for confirmation from at least one developer (preferably 2 or 3), that Sage builds on each supported platform before the release is made. Instead, 4.3.3 was released without confirmation Sage built on Solaris, and 4.3.4 was released without confirmation Sage built on SUSE, Fedora and what other supported platforms it broke on. I don't have time to find it now, but I've made the analogy before about how F1 teams tell the driver to go after there is confirmation that the process of changing tyres and/or refueling have been completed. It so happens in this case, Jaap Spies actually raised the issue Sage 4.3.4.alpha0 was broken on Fedora, but that was not noticed by the release manager. I don't critise the release manager for this, as it is unreasonable for them to notice every single email. But I believe the method should change to "Don't release until there is confirmation Sage builds on every supported platform". Currently the method is "Release if we don't see a report of a breakage". In fact, the method for Solaris has been even worst, as when I created a blocker ticket on some earlier release the build got broken on Solaris, (some other reason), the release still went ahead. 6). I believe the release numbers (X.Y.Z) should indicate something useful, not be semi-random. If this was done, it would be possible to allow 'sage -upgrade' to work if the changes are small (i.e. only if Z changes). 7) I've made the point before that there could be issues if Sage binaries are built with new GCC libraries and the person installing the library has only an older version. Whilst this issue is probably not related to gcc, the use of older libraries may well have caused the problem here. 8) You personally wrote a day or two ago you were intending making a Sage release in a day or so whilst merging 3 tickets. I suspect that release would have been made without confirmation Sage builds on all supported systems. I like the idea of "release early, release often", but I personally believe that should confined to developer shanshots, alpha/beta releases (call them what you want). Making public releases without fully checking seems a bad idea to me. Another example of a rushed change was the removal of Fortran compiler binaries, which was marked as a blocker and merged into sage-4.3.1.rc2 http://trac.sagemath.org/sage_trac/ticket/7485 I personally can't see why that was ever a blocker, as Sage had shipped with the fortran binaries for ages. After that last minute change, so it needed another blocker to add back the gfortran library http://trac.sagemath.org/sage_trac/ticket/8049 IMHO, if Sage is ever to become a viable alternative to Mathematica, Maple, MATLAB and Macsyma, you are going to have to shift the emphasis towards more thorough testing before making releases. I can't imagine Wolfram Research shipping binaries for platforms without testing them first. Of course bugs do occur, and what works on one machine does not necessary work on another. But it seems to me a lot of Sage bugs are avoidable. What I personally perceive as a lack of sufficient testing of Sage, leaves me questioning myself whether I ever want to use Sage. I've used Mathematica on and off for many years, and have come across bugs. But never have I come across bugs so easily avoided as I see in Sage. I'm trying to be constructive here, by pointing out what I believe are deficiencies in the current process of releases. I'll make a new package for iconv at the weekend if nobody beats me to it. Dave -- 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 To unsubscribe, reply using "remove me" as the subject.
