installation of optional spkg's on binary Sage releases

129 views
Skip to first unread message

Dima Pasechnik

unread,
Apr 16, 2015, 12:49:45 PM4/16/15
to sage-...@googlegroups.com
It seems to me that binary distributions are not guaranteed to be able to build some optional packages.
There were numerous reports on sage-support, and here is another example:
http://trac.sagemath.org/ticket/18198

However, reading http://sagemath.org/doc/installation/quick-guide.html
gives you a false impression to this effect.

Should the text in this link be adjusted to tell people to use source distros?

Dima

William Stein

unread,
Apr 16, 2015, 1:12:16 PM4/16/15
to sage-devel
On Thu, Apr 16, 2015 at 9:49 AM, Dima Pasechnik <dim...@gmail.com> wrote:
> It seems to me that binary distributions are not guaranteed to be able to
> build some optional packages.

Side question -- Is anything guaranteed to build all optional
packages? What's the current status of testing them? I keep raising
this issue...

> There were numerous reports on sage-support, and here is another example:
> http://trac.sagemath.org/ticket/18198
>
> However, reading http://sagemath.org/doc/installation/quick-guide.html
> gives you a false impression to this effect.
>
> Should the text in this link be adjusted to tell people to use source
> distros?
>
> Dima
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.



--
William (http://wstein.org)

Dima Pasechnik

unread,
Apr 16, 2015, 2:26:12 PM4/16/15
to sage-...@googlegroups.com


On Thursday, 16 April 2015 18:12:16 UTC+1, William wrote:
On Thu, Apr 16, 2015 at 9:49 AM, Dima Pasechnik <dim...@gmail.com> wrote:
> It seems to me that binary distributions are not guaranteed to be able to
> build some optional packages.

Side question -- Is anything guaranteed to build all optional
packages?   What's the current status of testing them?  I keep raising
this issue...

some optional packages are maintained, and tested by maintainers (and/or other users)
on a regular basis. But this is ad hoc, surely. And some are obsolete, like gcc 4.6.4 one.

Should we dedicate few patchbots to test optional packages?
 

Nathann Cohen

unread,
Apr 17, 2015, 2:41:02 AM4/17/15
to sage-...@googlegroups.com
Side question -- Is anything guaranteed to build all optional
packages?   What's the current status of testing them?  I keep raising
this issue...

If you ever get tired of raising the issue, maybe you could try doing something about it.

Nathann 

Dima Pasechnik

unread,
Apr 17, 2015, 4:37:22 AM4/17/15
to sage-...@googlegroups.com
But we digressed. Does anyone has an opinion about my original
question?

Thanks,
Dima

kcrisman

unread,
Apr 17, 2015, 10:50:10 AM4/17/15
to sage-...@googlegroups.com
 Until we have the infrastructure of R I don't think this will happen.  Which raises the question of how R does its whole CRAN and Rforge etc.

> But we digressed. Does anyone has an opinion about my original question?

Luckily it turns out (?) that http://trac.sagemath.org/ticket/18198 wasn't about this.  Maybe we should say something about optional packages *may* need a build from source.  I assume there are lots that don't, though, right?  (If all of them or nearly all do, that is different.)

Dima Pasechnik

unread,
Apr 17, 2015, 11:28:20 AM4/17/15
to sage-...@googlegroups.com


On Friday, 17 April 2015 15:50:10 UTC+1, kcrisman wrote:

Side question -- Is anything guaranteed to build all optional
packages?   What's the current status of testing them?  I keep raising
this issue...

If you ever get tired of raising the issue, maybe you could try doing something about it.

 Until we have the infrastructure of R I don't think this will happen.  Which raises the question of how R does its whole CRAN and Rforge etc.

> But we digressed. Does anyone has an opinion about my original question?

Luckily it turns out (?) that http://trac.sagemath.org/ticket/18198 wasn't about this.  

that's right. But I still recall sage-support threads where binary vs source was relevant. Maybe this has been all fixed.
(as well, there were relatively often binary builds that were not 100% clean, linking to libs which were not distributed along)
Perhaps the test is to see how much of Sage can be rebuilt when one only has a binary distribution.
(make distclean removes too much though :-))

 

William Stein

unread,
Apr 17, 2015, 11:34:28 AM4/17/15
to sage-devel
<defensive>
I have done things about the issues with optional packages.
For example, I wrote

https://github.com/sagemathinc/smc-public/blob/master/build.py

which I run with each new release, and which automates installing
every optional package I think people request or care about. I've
reported a lot of issues
as a result.

Sorry if I don't do enough for the Sage project...
</defensive>

William

>
> Nathann

kcrisman

unread,
Apr 17, 2015, 1:35:28 PM4/17/15
to sage-...@googlegroups.com
>
> If you ever get tired of raising the issue, maybe you could try doing
> something about it.
 
<defensive>

I think in this case the defensive is understandable.
 
I have done things about the issues with optional packages.
For example, I wrote

    https://github.com/sagemathinc/smc-public/blob/master/build.py

which I run with each new release, and which automates installing
every optional package I think people request or care about.   I've
reported a lot of issues
as a result.


Hmm, that sounds like something that would be very useful to have as part of the release process itself.  Does it only work in SMC, though?  (And if so, maybe it's not going to catch all binary things since linking etc. would all be identical on identical SMC instances?  Excuse me if I overreach, because obviously I don't understand the internals of SMC too well, just wondering.) 

William Stein

unread,
Apr 17, 2015, 1:42:00 PM4/17/15
to sage-devel
That in this case is a Python script that tries to install everything
to make the heavily enhanced version of Sage that people get when they
use Sage on SMC. But anybody could use it if they wanted the same
enhanced sage. It's mostly automated, but there's a step or two that
isn't right now...

William

kcrisman

unread,
Apr 18, 2015, 8:35:20 PM4/18/15
to sage-...@googlegroups.com

That in this case is a Python script that tries to install everything
to make the heavily enhanced version of Sage that people get when they


BTW, a bit OT but any enhancements there that could be reported downstream to "Sage proper"? (I mean without someone doing a lot of digging for them.)  I assume that some like three.js stuff would take some work, but maybe there is some other stuff.
Reply all
Reply to author
Forward
0 new messages