Le mercredi 25 octobre 2017 18:10:10 UTC+2, Erik Bray a écrit : > > On Wed, Oct 25, 2017 at 5:42 PM, Emmanuel Charpentier > <emanuel.c...@gmail.com <javascript:>> wrote: > > I need an example of a standard package not installed if present > systemwide > > : I know there are some, but can't retrieve it right now... > > gcc >
<Slaps forehead> Of course ! Thanks a lot ! -- Emmanuel Charpentier > > > Le mercredi 25 octobre 2017 17:38:20 UTC+2, Emmanuel Charpentier a écrit > : > >> > >> Proposal for implementation of OpenSSL inclusion in Sage. > >> > >> The inclusion of OpenSSL in Sage has been decided after a long and > >> fruitful discussion. Now remains to implement it… > >> > >> The case of installing Sage without OpenSSL is addressed in a separate > >> thread (to be posted RealSoonNow). > >> > >> Since the OpenSSL relicensing is still underway, the “obvious” way > (make > >> openssl a standard package, and be done with it) canot be done (yet : > that > >> will be the end of the story…). The following proposal deals with the > >> transitional period until this relicensing. > >> > >> The ticket #24107 has been opened on Track. However, it seems more > useful > >> to keep the discussion here, dedicating the exchanges on Trac to > technical > >> implementation issues. > >> > >> Licensing clarification > >> > >> The incompatibility between GPL and OpenSSL Licenses does not seem to > >> amount to much > >> > >> R, which is GPL-licensed, depends on an https-enabled SSL (i. e. > OpenSSL), > >> without discussing it. > >> Wget, a GPL-licensed Gnu utility, depends on OpenSSL, and has added the > >> following language to its license : > >> > >> "Additional permission under GNU GPL version 3 section 7 > >> > >> If you modify this program, or any covered work, by linking or > combining > >> it with the OpenSSL project's OpenSSL library (or a modified version of > that > >> library), containing parts covered by the terms of the OpenSSL or > SSLeay > >> licenses, the Free Software Foundation grants you additional permission > to > >> convey the resulting work. Corresponding Source for a non-source form > of > >> such a combination shall include the source code for the parts of > OpenSSL > >> used as well as that of the covered work." > >> > >> That (modulo sed -e"s/Free Foftware Foundation/Sage/g", of course) > seems > >> to cover all possible recourse against us except possibly their use of > GPL > >> version 3 rather than 2. GPL exegetes, there is your opportunity to > speak > >> up… > >> > >> However, in the relevant pieces of documentation (mostly README, I > think), > >> we may add the following blurb : > >> > >> "Sage depends on the availability of the OpenSSL software library (a > piece > >> of software that allows secure > >> communications between your computer and servers used to download parts > of > >> the system) in your system software. > >> It is likely that this library is already present on your system. If > you > >> are using a pre-compiled packaging of Sage, such > >> as the Windows distribution, a Debian, Red Hat or Gentoo package or a > >> Macintosh package, these packages depend on > >> the necessary library, that will be automatically installed on your > >> computer from the official source of your software > >> package." > >> > >> In the Installation Guide, the same language could be inserted in the > >> relevant “binary installation” part. In the “compiling from sources” > part, > >> ditto, but add : > >> > >> "However, due to its current licensing terms, Sage can be linked > against > >> (i. e. built in order to work using) this library, > >> but we cannot host it on our servers. > >> > >> If this library and its header files are not currently installed, the > >> installation script will offer you the choice of > >> * downloading OpenSSL sources from the OpenSSL repository, for > >> installation in the Sage tree only, or > >> * aborting the installation, in order to let you install OpenSSL > >> systemwide > >> In the first case, OpenSSL will be used only by Sage and its hosted > >> software, such as Python and R. In the second > >> case, OpenSSL will become available to all your installed programs." > >> > >> Actual implementation > >> > >> Binary packages > >> > >> Distributions with a reliable dependency system (all Linux and freeBSD > >> major distributions, to the best of my knowledge) : they can simply > depend > >> of the distribution’s OpenSSL library package. > >> Cygwin : Erik Bray tells that Cygwin’s openssl package is installed by > >> default ; therefor, his binary packaging can ensure that the relevant > >> library is present. > >> Mac OS : This seems possible for most supported OS X versions ; I defer > to > >> the expertise of our Mac developpers. > >> Other Unices : I don’t know… > >> > >> In short, we need practical advice on how to cope with various versions > of > >> Mac OS and non-Linux, non-FreeBSD unices (which are a bit exotic, > >> nowadays…). Advice welcome. > >> > >> Source tarball > >> > >> There, things begin to be interesting : > >> > >> We can’t (yet) “just” make a “normal” standard package of openssl : > that > >> would entail hosting it on the Sage mirrors, which is, in the opinion > of > >> some, “illegal” (in which legal context ?). > >> Furthermore, the existence of a systemwide openssl makes this inclusion > >> futile. > >> > >> We can use a procedure that I’m said to be used for some of our > standard > >> packages : the toplevel configure script : > >> > >> tests for the existence (and, if necessary, the characteristics and > >> abilities) of a package ; > >> if not found : adds it to the list of packages to be installed ; > >> if found : marks it as installed (with the real version). > >> The “normal installation process takes care of : > >> > >> if necessary, downloading the necessary source tarball from (one of) > the > >> Sage mirror(s) ; > >> building and installing the package in the $SAGE_ROOT tree ; > >> optionally running its testsuite. > >> > >> The step 2. cannot be used “raw” in openssl’s case : the normal > >> installation process would fail at the download stage. We can : > >> > >> “Blindly” depend on openssl libraries and headers being present > >> systemwide, fail if not present with a (loud) error message for a > missing > >> dependency ; > >> Download the original, pristine, OpenSSL tarball from OpenSSL site > >> directly to $SAGE_ROOT/upstream, then proceed as for a “normal’ package > ; > >> > >> I propose that we combine those steps in the following manner : > >> > >> create a standard package for openssl, but do NOT upload its tarball to > >> the Sage mirrors ; > >> replace step 2. above (i. e. what happens when a systemwide OpenSSL > isn’t > >> found) with the following : > >> > >> Query the user with the choice : > >> > >> “Download OpenSSL from its original site, then do the installation in > the > >> local Sage tree” > >> “Abort this installation, to be restarted after installation of a > >> systemwide OpenSSL (recommended)” ; > >> “Abort, and download a tarball allowing for installation without > OpenSSL”. > >> > >> According to the choice of the user : > >> > >> Download from OpenSSL site directly to $SAGE_ROOT/upstream then proceed > ; > >> Display a hint for systemwide installation, then abort ; > >> Display the adress of an OpenSSL-less Sage tarball, then abort. > >> > >> Important corollary > >> > >> All traces of our current, outdated and probably (pseudo-)illegal > openssl > >> package must disappear. > >> > >> Also, looking for optional packages, I see : > >> > >> charpent@p-202-021:~$ sage -optional | grep openssl > >> openssl.................................1.0.2j (not_installed) > >> pyopenssl...............................17.3.0 (not_installed) > >> > >> I do not understand why. Is my last installation too old ? The questoin > >> goes to mirrors administrators and possibly present and past release > >> managers. > >> > >> ________________________________ > >> > >> What do you think ? Advice, criticisms, lazzi and even koans welcome. > >> > >> HTH, > >> > >> — > >> Emmanuel Charpentier > > > > -- > > 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 <javascript:>. > > To post to this group, send email to sage-...@googlegroups.com > <javascript:>. > > Visit this group at https://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > -- 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.
