Re: Crypto Libs: Linking to OpenSSL, GnuTLS, NSS, ..?
> you will not get rid of either crypto stack
Thanks for everyone's comments. Sorry for the confusion introduced. I
like one package each with a different crypto-library backend. Then, it
is about user's choice rather than getting rid of something.
My (observed) problem: Many projects *default* to one crypto library in
their build system, sometimes not OpenSSL. However, the project supports
more crypto libraries. Actually, the project – I am about – officially
maintains and prefers OpenSSL as crypto-library backend, although it is
not picked on default in their build system (for legacy reasons).
And its package maintainer did not notice alternatives existed.
My question was: Has anyone before evangelist on a Debian package
maintainer to *add* another (-lib and -dev) package, with OpenSSL as
crypto-library backend (or even more/all other crypto libraries) the
upstream project supports? Very much like Curl does it right now. What
could be arguments/reasons to convince the maintainer?
Reply to: