> 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?
