On Sep 28, 5:29 am, "Georg S. Weber" <[EMAIL PROTECTED]>
wrote:
> 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.
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. 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.
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)
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.
-Tim Abbott
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
