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...
-- 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 > <https://groups.google.com/d/msg/sage-devel/fE45025Wphs/rZ0xwAyJCAAJ> > after a long and fruitful discussion > <https://groups.google.com/d/msg/sage-devel/fE45025Wphs/mKdCAeNhAgAJ>. > 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 <https://trac.sagemath.org/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 > <https://groups.google.com/d/msg/sage-devel/fE45025Wphs/I0EQ8RraCgAJ> > 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 : > > 1. tests for the existence (and, if necessary, the characteristics and > abilities) of a package ; > 2. if not found : adds it to the list of packages to be installed ; > 3. 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 > <http://www-ftp.lip6.fr/pub/math/sagemath/spkg/upstream/openssl/index.html> > 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+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.
