(Sorry for the multiple replies--there are just a lot of disparate
issues touched on in this message that I think would be confusing to
reply to all at once).
On Tue, Oct 24, 2017 at 8:58 PM, Emmanuel Charpentier
<emanuel.charpent...@gmail.com> wrote:
> This point of view is of course incompatible with the result of the vote.
> However, I think that it could be easy to maintain a set of patches allowing
> such a compilation without SSL. This set of patches could live in a git
> branch (say "anchorite" (a solitary kind of sage)) of our tree, and updated
> to create releases (in sync with Sage "official" releases ?) and related
> tarballs and binaries. Of course, I emphatically DON'T volunteer for this
> maintenance...
a) I don't think the point of view (that it should be possible to
build Sage without SSL support) is incompatible with the vote. The
vote was over whether or not to include OpenSSL as an spkg (optional
or otherwise). It could still be required by default, but disabled by
a configure option, for example, if needed. In fact, as we've
repeatedly discussed, the *only* package in Sage that won't compile if
it doesn't find OpenSSL (actually libcurl with SSL support,
technically) is R. So in practice the implementation might be
something like:
a) Check for OpenSSL in Sage's configure
b) If not found, use Sage's OpenSSL spkg
But part b) could also hypothetically be disabled by a configure flag,
if really necessary, *except* for the fact that then the R build will
fail. This takes us to the issue of "a set of patches" (in reality
there is only a singular patch, the patch to R's configure to allow it
to proceed without an SSL-enabled libcurl).
I've repeatedly said I'd be willing to take the argument about this to
R-devel (so I can get out of your hair about it :) But I don't think
it's all that big a deal either. In fact, the issue of building R
could also be resolved entirely without a patch by just tricking it
into thinking it has the libcurl it's looking for. I wouldn't
recommend this approach, but it can certainly be done even without
patching :)
> It has been noted that we should bill Apple for all the time we wasted on
> maintaining Sage on their platform notwithstanding the difficulties posed by
> the oddities of their development tools.
>
> While applauding the idea, I am skeptical about its implementability.
> Comments ?
TBH Microsoft has a better track record these days of funding open
source software than Apple does :)
Best,
Erik
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
