| 1 |
Hello, |
| 2 |
|
| 3 |
I'd like to ask for an advice related to net-im/ekg2 ebuild. I would |
| 4 |
like to switch the ebuilds there to use the primary autotools build |
| 5 |
system for the package, and the last thing on my to-do list is adding |
| 6 |
a 'ssl' flag to the package. |
| 7 |
|
| 8 |
The package consists of a core application and a set of plugins which |
| 9 |
are built in a single run and build of which can't be easily separated |
| 10 |
from the core application build (and I'd like to avoid forcing upstream |
| 11 |
to split it). |
| 12 |
|
| 13 |
The package configure scripts checks for both GnuTLS and OpenSSL |
| 14 |
as a SSL backend. However, the use of a particular backend is |
| 15 |
plugin-specific. |
| 16 |
|
| 17 |
In particular, both Jabber and remote plugins support using either |
| 18 |
GnuTLS or OpenSSL as the SSL backend. If both are available (enabled), |
| 19 |
GnuTLS is preferred and used. On the other hand, the IRC plugin |
| 20 |
supports OpenSSL only, and the sim plugin relies on OpenSSL. |
| 21 |
|
| 22 |
In other words, the preferred complete build of ekg2 requires both |
| 23 |
gnutls and openssl. However, all of the features should work fine with |
| 24 |
openssl itself as well. |
| 25 |
|
| 26 |
Right now, the ebuild uses 'gnutls' and 'openssl' flags to control |
| 27 |
enabling each of the backends. To simplify that for the user, I'd like |
| 28 |
to add a 'ssl' flag as well. The question is -- how should that flag |
| 29 |
behave, taking care of the situation I described above? |
| 30 |
|
| 31 |
-- |
| 32 |
Best regards, |
| 33 |
Michał Górny |
Archives