Mark your fourth option seems to me like a great solution in the long term, but I'm worried about the feasibility of doing it before reaching the LTS Feature Freeze for that package to be MIR-ack, being a NEW package first.
In the short term, should it be upgrading tomcrypt to the latest upstream commit and checking if that codebase is easier (or not :( ) to split it in terms of creating libcryptx-ed25519-perl something we can do to get this feature of DKIM included for the LTS? Keeping in mind that I(we) am committed to get libcrypt-openssl-ed25519-perl as a proper solution later on as soon as possible.
Any other ideas are also welcome if both solutions above can be considered risky because of the time we have to do it.
Hi Mark, Christian,
Mark your fourth option seems to me like a great solution in the long term, but I'm worried about the feasibility of doing it before reaching the LTS Feature Freeze for that package to be MIR-ack, being a NEW package first.
In the short term, should it be upgrading tomcrypt to the latest upstream commit and checking if that codebase is easier (or not :( ) to split it in terms of creating libcryptx- ed25519- perl something we can do to get this feature of DKIM included for the LTS? Keeping in mind that I(we) am committed to get libcrypt- openssl- ed25519- perl as a proper solution later on as soon as possible.
Any other ideas are also welcome if both solutions above can be considered risky because of the time we have to do it.