> About the complexity in the long-term: how feasible would it be to upgrade to a new version of this
> package with new features

We don't have to upgrade, we can patch the ed25519 support in. Basically the revert of you patches here.

It's still a new feature, of course, and one could argue it's a delta as complicated as the one here dropping the patches. So updating the version might be less risky. Both scenarios, however, will require an FFe for noble. Personally, I would prefer upgrading to 1.20240124-1 when the time comes.

So let's think about the scenarios:

a) Proceed as planned with this MP, which means:
- remove Ed25519 support from src:libmail-dkim-perl now, and upload
- that will make src:libmail-dkim-perl migrate
- feature freeze happens without Ed25519 support

Then:
- fingers crossed that security ACKs MIR LP: #2023971 for src:libmail-dmarc-perl
- the Ed25519 perl+openssl wrapper happens, passes NEW review, goes into noble
- we restore Ed25519 support in src:libmail-dkim-perl by dropping these patches, get an FFe, upload to noble
- change src:spamassassin to again recommend (instead of suggest) bin:libmail-dmarc-perl (its MIR was supposedly accepted above)


b) Revert to src:libmail-dkim-perl 1.20230212 in noble, without Ed25519 support
- remove src:libmail-dkim-perl 1.20240124-1 from noble-proposed
- upload src:libmail-dkim-perl 1.20230212-1ubuntu to block syncs
- feature freeze happens without Ed25519 support

Then:
- fingers crossed that security ACKs MIR LP: #2023971 for src:libmail-dmarc-perl
- the Ed25519 perl+openssl wrapper happens, passes NEW review, goes into noble
- we restore Ed25519 support in src:libmail-dkim-perl. Either updating to 1.20240124, or patching Ed25519 in taken from the 1.20230630 version. FFe required
- change src:spamassassin to again recommend (instead of suggest) bin:libmail-dmarc-perl (its MIR was supposedly accepted above)



So.

If all goes to plan, in *both* cases we will need a FFe for src:libmail-dkim-perl with the Ed25519 feature put back, either via a patch, or a version bump to at least 1.20230630, or preferably (just because it's the sync from debian) 1.20240124-1.

If something fails along the way (MIR is not granted for src:libmail-dmarc-perl, or the new openssl ed25519 perl wrapper doesn't happen in time, or is not reviewed in NEW in time, etc), then we have differences.

In the failed (a) case, we will have in noble a src:libmail-dkim-perl package with Ed25519 patched out. That delta is unlikely to apply cleanly on version upgrades, but that shouldn't happen in noble SRUs. This has the "unexpected" feeling (to me) of a newer version of a package with a feature dropped by us as a delta. If we manage to unfail things after noble was released, an SRU would just remove that patch, and by that, add a new feature.

In the failed (b) case, we will have in noble a normal src:libmail-dkim-perl package, just behind debian, without Ed25519. After we "unfail" this, the SRU would be to add a feature by either adding ed25519 via patches, or bumping the version. This might be psychological, but personally I feel that removing patches has less risk than adding them, or bumping the version.


If we are confident that we can get this work for noble release, then I'm leaning towards (a). Otherwise, (b), because then we will have src:libmail-dkim-perl in noble without heavy patches dropping Ed25519.