ntl
* Bernhard R. Link <brlink@debian.org> [110808 17:12]:
> The branch, master has been created
> at bac15db8073856e14e20eaecdc5423eaf404cdc8 (commit)
> - Shortlog ------------------------------------------------------------
> commit bac15db8073856e14e20eaecdc5423eaf404cdc8
> Author: Bernhard R. Link <brlink@debian.org>
> Date: Mon Aug 8 17:05:56 2011 +0200
>
> Preview packaging of ntl 5.5.2
>
> - named source package differently (to allow it and the previous
> version to stay around at the same time for some time)
> - upstream uses libtool with proper soname, so it's libntl0 now
> - changed -dev name (temporarily) to avoid confusion with old -dev package
> - repackage using plain debhelper instead of cdbs
> - add multiarch support
> - "3.0 (quilt)" format source package
I've uploaded something to have a basis of discussion (and so someone
wanting to look at other packages has already something to base the work
on).
As upstream now used libtool with --version-info, so hopefully will get
proper soname handling, thus the binary package is now libntl0
(as the soname is libntl.so.0).
I've changed the source name to libntl and the -dev package name to
libntl0-dev to avoid any conflicts with the version currently in Debian.
(I think if this will reach Debian it should at least get the -dev back
to libntl-dev).
It's compiled using libgmp but not gf2x (that isn't yet in Debian or
have I overlooked it?).
The patches seem to be all upstream or have something similar upstream,
so I guess all but the one from the last NMU are no longer needed.
Some files still need updating/adding:
debian/copyright debian/watch debian/libntl0-dev.doc-base
Open issues:
* The build process creates a mach_desc.h from testing the
build machine. I'm a bit uneasy about especially one part
of it: register extended doubles.
If it finds those active of the build machine, it adds on
i386/Linux some code to change some register to disable
that behaviour whenever doing operations that might effect.
Does anyone know if those register is garanteed to be set
on i386/Linux? If that is variable, a buildd might not have
set it, thus the setting not compiled in thus the library
producing different behaviour on other machines.
(As I read it, that flag is almost the only one not directly
calculateable from values in limits.h or stdint.h, so it
might make sense to patch that file with a static architecture-
independant variant and just check at compile them whether the
assumptions are true, instead of calculating those at runtime).
* Symbol files would be nice. A c++ library isn't the most easy
case, though.
Bernhard R. Link
Reply to: