I mentioned the polymake problem a while ago, with a simple fix (just changing the version of cddlib it points to), and Michael wanted to do a more complete/automatic fix, so it rotted quietly for a while. But I have been installing it off and on since then by manually changing the spkg install. It builds fine on my intel macs after that.
The native sage polytope functionality is improving at a pretty good pace now, hopefully in the next year we can do almost everything that polymake can. There are a number of nice things that polymake can do that require non-free java guis, which presumably we would never include anyway, so some of the remaining gaps in functionality require us writing new code anyway. That was one of the main reasons I thought it was worthwhile to work on native sage implementations. As long as I'm talking about that, could someone please review #4676? It didn't make it into 3.2.2 because of no review. -Marshall Hampton On Dec 24, 8: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 :) > > > > See: http://trac.sagemath.org/sage_trac/ticket/4868 > > Seehttp://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. > > > 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.. > > > * 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. > > > * 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. > > > * 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. > > > * 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. > > > 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. > > > 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. 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. > > > -- William > > Cheers, > > Mihcael --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
