On Wed, Dec 24, 2008 at 6:10 AM, mabshoff <mabsh...@googlemail.com> wrote: > On Dec 23, 11:13 pm, "William Stein" <wst...@gmail.com> wrote: >> On Tue, Dec 23, 2008 at 11:02 PM, William Stein <wst...@gmail.com> wrote: >> > Hi, > > Hi, > >> > I propose moving the polymake spkg to be experimental instead of >> > optional. If anybody cares, please respond to this email. It's >> > crystal clear having looked at the polymake spkg tonight that not a >> > single person has successfully installed polymake in several months. > > Not true, it is that the version in the repo has been broken :)
Just for clarification, it is true that nobody has installed the polymake in the repo for months. I'm removing it from the repo. If somebody produces a polymake that works, then we can consider adding it back to the repo. It is now gone. > >> > See: http://trac.sagemath.org/sage_trac/ticket/4868 > > See http://sage.math.washington.edu/home/mabshoff/polymake-2.2.p5.spkg > and the ticket #3640. Polymake is a prime example where sticking > things into the optional or experimental spkg repo without proper > review and an active maintainer is wrong. I don't care much what goes into experimental. Optional definitely needs a new standard. >> Hi, just responding to myself here, the following optional spkg's all >> fail to install on sage.math (a standard Ubuntu box): >> >> dvipng-1.8 >> gcc-4.2.1 >> hermes-0.9.4-linux >> jmol-11.5.2-src-v2 >> polymake-2.2.p4 >> >> I would like to deprecate all of them to experimental. Reasoning: >> >> * dvipng-1.8 -- available on any linux/os x system via standard >> package tools; has nothing to do with sage > > Delete it completely. The dependencies are insane and people just > install the distributions version.. Done. > >> * gcc-4.2.1 -- this spkg exists only because Michael made it so I >> could try to build sage on some weird systems where the system-wide >> compilers were crap. It doesn't build on sage.math now, and it's not >> something almost anybody should use. > > Well, that is because Sage seems to be missing 32 bit userspace. That > is an installation issue, but I am fine with moving it to experimental > or even deleting it. I have a gcc 4.3.2.spkg, but I am sure that will > also fail currently on sage.math. But monkeying around and custom > fitting things for sage.math is just wrong, i.e if dependencies are > missing it just won't work. The *right* solution should be that as soon as I try to install the spkg, it fails with an error that says "install 32-bit userspace" and some hint as to what the heck that means. Having it fail halfway in with a completely mysterious error isn't any good. Anyway, gcc-4.2.1 is pretty old -- even Ubuntu 8.04 LTS ships a newer gcc. I've moved this to experimental. > >> * jmol-11.5.2-src-v2 -- this spkg exists to demonstrate that in >> theory jmol can be built from source. I don't think anybody actually >> has ever used it. Better would be a web page that contains the spkg >> and instructions on how to use it to make the binary spkg. > > This probably fails because because the Sun Java JDK isn't installed. > jmol never worked with the gcj toolchain, so no surprise here. I actually didn't try it before. OK, trying it now, and it fails in a second. The java compiler on sage.math is: ---- Eclipse Java Compiler v_774_R33x, 3.3.1 Copyright IBM Corp 2000, 2007. All rights reserved. --- A correct spkg that can only build with one specific compiler (say sun's) should just say so at start and exit gracefully if that java isn't available. >> * hermes-0.9.4-linux -- a binary-only spkg that doesn't (and doesn't >> fail gracefully) on any system I have. I don't even know what it >> does. I don't know where it came from. It hasn't been touched in >> nearly three years. > > This was discussed in another thread and we should just remove it. Done. > >> * polymake-2.2.p4 -- I don't know if this builds on anything. See >> above. Since Sage doesn't binary link to polymake at all, it is >> better if polymake is installed from some official polymake binaries >> or whatever completely independent of sage. > > Well, I fixed it. When there is a reviewed spkg that works, we can add it back to optional. > >> I want the Sage "optional" packages to *all* install fine on every >> system that we officially support Sage on. > > No chance this is going to work. 1. Just because you don't know how to do something doesn't mean it can't work. 2. If I listened to naysayers Sage wouldn't exist. In any case, if I clearly define what supported OS means, and am carefully about what goes in the optional spkg repo, the above *will* work. This was always the intention. The only reason it isn't realized now is that nobody has seriously worked on it. > >> There should be a single >> command to easily install *all* of them, and another easy way to run >> all relevant optional doctests (that depend on all the free optional >> spkg's). > > That won't work either. See 1 and 2 above :-) > All we can shoot for is to get them all > working on sage.math. There are also optional doctests in sage that > depend on experimental spkgs like M2. And M2 does not build on Solaris > as is for example. Bad example, since Sage doesn't build on Solaris as is. Solaris isn't an officially supported OS to run Sage on yet. > >> -- William > > Cheers, > > Mihcael > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
