Hi Martin, Michael, Tim, and [sage-devel], Michael did propose two solutions for certain problems:
1. move all library versioning patches to the Debian packaging directory 2. provide makefile targets to obtain unversioned libraries Thinking about it, a third solution comes to my mind, let me explain how I got there. In the past, all "packages" (say e.g. Pari, Flint) were taken from their source destination, and then directly "spkg" were made out them. If libraries were provided, they were put under $SAGE_ROOT/local/lib, and it was tried hard to make sure, that the system linker/loader was taking these, and not any other version of them somewhere lying around. The "debianization" of Sage means (among other things) that certain packages that already existed as debian packages are "taken out of Sage" (Pari), as well as some other packages, which were "made into" debain packages in that process. The libraries provided by these "debianized" packages are no longer under $SAGE_ROOT/local/lib, but the debian system has to know itself where to find them (not really, see below). On non-debian (or better, non-GNU/Linux) systems, and even on debian systems also, it might not only be favorable, but a sheer necessity to be able to install not the "debian version" of a package, but the "spkg" version. For example, the Pari "spkg" does patch (directly in the sources) the exit/abort behaviour, and one might want to use this patched version of Pari, even on a Debian system, where the "debian" upstream Pari does (and shall) not have this exist/abort patch. This directly leads to a third solution to the problems Michael sees: 3. For those packages, that are "debianized", the input for creating a corresponding "spkg" is no longer the raw source, but the "debianized version", i.e. a debian package. In the spkg-install script, one can (and does) patch the sources and the build process anyway, by these means one ensures that the libraries created are put under $SAGE_ROOT/ local/lib and nowhere else. And any soname versioning is simply patched out, if it causes trouble. And Sage works with either the "original debian" or with the "spkg" version of a package, the latter having priority if it is installed. To follow this way seems necessary to me, if one wants to ensure that the Sage "debian" branch and Sage "mainline" branch do not diverge too much. Perhaps one has to create "fake" or "virtual" debian packages from time to time, but that's not too much additional effort. Certainly not compared with the benefit of "keeping mainline and debianization together", but even in "absolute" time. As for those packages that had been "debianized" in the process, it is pretty easy to provide the "spkg" using the new "debian" package as input: just replace (in spkg-install) the new build structure (makefiles and such) by the old ones, which are still in the repository, and are known to work. And the introduced soname versioning will just disappear, too :-) The Windows native 64-Bit port in mind, it seems to be necessary anyway, to use the flexibility of "doubling a package's build structure" here and there. Admittedly, there is one drawback to solution 3), which needs further discussion: In "devel/sage/setup.py", the environment variable "SAGE_DEBIAN" currently is used as a master switch for all those packages, to add each and every of the "debian_include_dirs" at once. Things might work well nevertheless. But if not, it's time anyway to clean up this "grown over the years" file, there is more than one trac ticket addressing this (e.g. #2732). At last, one word concerning the use of "libtool". For Sage purposes, this seems to me to be like "shooting with cannons on sparrows". In my eyes, it does make sense to (newly) introduce the use of libtool, automake, autoconf for one of the debianized packages, if and only if that package is intended to be spreaded to "the world" not only as a debian package, or as a part of Sage, but also as a standalone (!) package under Solaris, BSD, and other "non-GNU/Linux" systems. Which is well worth some effort. But that clearly is orthogonal to Sage, and the needs of Sage. Cheers, gsw --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
