On Sep 28, 10:16 am, Tim Abbott <[EMAIL PROTECTED]> wrote:
> On Sep 28, 5:29 am, "Georg S. Weber" <[EMAIL PROTECTED]>
> wrote:
Hi,
> > 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.
Sage is self contained for a reason since any other setup while using
components from the system is sure to cause endless trouble, i.e. just
imagine debugging a Sage setup where ten components are provided by
the system. IMHO there will only be one official and supported version
of Sage and that will be the official, vanilla tarball. Whatever
distribution package will be close, but not identical. I also doubt
that any distribution will keep up with Sage releases and we do not
have the manpower or interest to support stable releases of Sage.
William has always claimed that once development calms down this will
be possible, but he said that a year ago and since then development
has sped up and not slowed down. I think that any Sage in Debian
stable will be useless after six months while the version in Debian
testing might have a chance to stay somewhat close to current.
> Library versioning is really supposed to be maintained upstream, since
> they're the people who know which interfaces have been broken and thus
> when version bumps are required. It also avoids every distribution
> maintaining its own patch for library versioning for a particular
> piece of software.
>
> Once the library versioning gets merged upstream, however, Sage then
> must either patch the upstream build system (which seems annoying to
> maintain) or use the versioned library.
We don't have to patch the build system, we have to do some post-
processing of the installed libraries which is mostly trivial. If
upstream goes with versioned libraries I will not fight it, but
complain if it breaks due to GNUisms. If upstream does not fix the
problem I will patch it out of their build system :)
> Because Sage is ported to
> Solaris, BSD, etc., this means the versioning must support all these
> non-GNU/Linux platforms as well. I probably should have thought about
> this more before submitting my versioning patches upstream.
Well, I did not complain vocal enough, so some patches were written
that will likely end up being discarded. Wasting code and effort is
always a bad thing.
> I think it may be helpful to be concrete about which packages are
> involved. The packages not already using automake that Francois
> Bissey and I have added shared library versioning to are the
> following:
> symmetrica (here the upstream makefile is like 3 lines long)
> singular (has a rather complex build system using autoconf but not
> automake)
> flint (makefile build system)
> zn_poly (uses a python script to write a makefile)
> ntl (uses a perl script to write a makefile)
> polybori (uses scons; versioning was added by the upstream developers)
> tachyon (uses a makefile; here there was previously only a static
> library)
The build system for ntl certainly sucks, but it is a cross platforms
build system that actually has supported MSVC for probably a decade.
That makes it pretty unique for any mathematical software library out
there. I seriously doubt you can convince Victor Shoup to use
autotools for NTL.
> Almost all of these projects have an active userbase outside of Sage.
>
> I should probably also comment on the current state of the SAGE_DEBIAN
> setup.
>
> Because my Sage packages are now in Debian (rather than in my Sage
> Debian apt repository), I'm no longer building Debian packages from
> the Sage sources (I need to use clean upstream sources for packages
> distributed in Debian, and it's easier to be sure that I've got clean
> upstream code if I download from the upstream website). So, the dist/
> debian directories in spkgs are currently unused. Those directories
> should perhaps be cleaned up, since I certainly don't have to time to
> maintain them for building new Debian packages after every Sage
> release in a Sage Debian apt repository (which is the only use they
> might have at this point).
>
> I do have an easy mechanism for using the Sage version of a particular
> spkg, rather than the Debian version for the Sage build (I have a list
> of spkgs that are built when I build the Sage package, included
> sage_scripts, examples, extcode, etc., and could add pari to that list
> if necessary). But I try to avoid this whenever possible; ideally,
> these bugfixes should be sent to the upstream developer and fixed for
> all Debian users, rather than just in Debian's Sage package.
Our patches go into upstream, some times not as fast as they should.
The main issue I have with using Debian packages is that once stable
comes out they are frozen. One example is Maxima where 5.14.0 made it
into lenny, but not 5.16.x. Once Sage in Debian is upgraded to 3.1.1
or higher you *must* upgrade to Maxima 5.16.x because the Maxima
developers changed the name of a function we rely on for the pexpect
marker. Ironically older Maxima version pass some doctests like
calculus.py, but since Maxima throws an error after each marker it is
restarted after each marker and running the doctest takes forever (it
is about eight times slower than usual).
This is a prime example why Sage is self contained and believe me:
This problem took a while to track down and fix. And this was not a
subtle issue, i.e. wrong mathematical results in some rare case, but
outright crashes each time we send something to Maxima. Sure, you can
fix either the Sage sources by detecting the Maxima version or put
some workaround in Maxima 5.14.0 itself, but that is not something
that will go into Sage since I am against any sort of cruft being
added. If you want to run Sage with something else than the
"officially blessed" components you are on your own. We have enough
bugs to fix in Vanilla Sage so that we don't need to go out and start
looking for trouble :)
> -Tim Abbott
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
