Re: Bug#242666: libgcrypt7 is not supported
On Wed, Apr 14, 2004 at 09:44:01 +0100, Colin Watson wrote:
> It is very painful to change the version of libgcrypt7 in base at this
> point. Doing this will break debian-installer testing, which is the reason
> we asked for no further changes to the package lists in the base system.
> debian-installer beta3 had to be re-released due to the last
> libgnutls/libgcrypt change.
I realise it will be painful to make this transition, but the benefits
Werner lists (in particular, avoiding future ABI breaks and avoiding the
problems we already see with processes that load two versions of gcrypt
simultaneously) outweigh the pain by quite a bit IMHO.
> If you are still considering this, you must coordinate very closely with
> the debootstrap maintainers and debian-boot.
Ivo works a stress ball's throw away from one of the debootstrap maintainers
(me), so coordination with regards to debootstrap shouldn't be a problem.
On Wed, Apr 14, 2004 at 11:27:07 +0200, Werner Koch wrote:
> I was not aware of the wide use Debian suddenly made of libgcrypt, despite
> that libgcrypt was flagged as work-in-progress.
It's a side effect of our wide use of GnuTLS in order to avoid the issue of
needing explicit exemption clauses in order to be able to redistribute
works based on GPLed code that use the OpenSSL library.
Also, it's not as wide as current Debian binary package dependencies may
lead you to believe. Quite a few binary packages specify a Depends: on a
version of libgcrypt while their executables don't reference symbols from
libgcrypt directly but just happen to be linked to libraries that do. This
is an artefact of how older versions of libtool used to work. Relibtoolising
their source packages will contain the libgcrypt dependency to just those
libraries; I've already done this for several of the GNOME packages (which
suffer from other inflated library dependencies as well, primarily on
libgnutls, libtasn and libaudiofile).
Ray
--
Subtlety is fine. It might warrant a comment, though.
Linus Torvalds
in <Pine.LNX.4.21.0104240838040.15642-100000@penguin.transmeta.com>
Reply to: