Per bugs 1092631 823492 841909 842015 842334 842908 845565 853066
559101 801247 and 795368, it would be really neat if any machine that
had evolution installed didn't also mandate pinentry-gnome3.

desktop pulls in evolution.  evolution pulls in evolution-data-server.
evolution-data-server mandates gnome-keyring.  Gnome-keyring (probably
sensibly) mandates pinentry-gnome3.

But evolution doesn't appear to actually need gnome-keyring.  Maybe
"recommends" would be a better option?  Or
gnome-keyring|pinentry-gtk2|pinentry-qt (still only recommends,
because you don't *need* gpg keys in order to be able to read and
answer email) or something like that.

I believe e-d-s mainly needs gnome-keyring so it can save the passwords
for your IMAP/POP/SMTP account, rather than for GPG, and that *is* a
blocker for reading and answering email (unless you re-enter the password
every time, but that encourages use of weak passwords).

If other implementations of the "Secret Service" D-Bus API
(org.freedesktop.secrets) also work equally well (which I cannot confirm
or deny, an evolution maintainer would have to answer that), then it
could perhaps depend on

    gnome-keyring | libkf5wallet-bin | keepassxc

like python3-secretstorage does? But I suspect that dependency is out of
date now that we have KDE Plasma 6 components - maybe the second option
should be kwallet6?

Or perhaps gnome-keyring | kwalletmanager, like libqt6keychain1 has, is
a better dependency? I don't really know the KDE side of this ecosystem.

Unfortunately I don't think there is currently a virtual package
representing all packages that implement org.freedesktop.secrets.
If there was, then it could depend on
gnome-keyring | org.freedesktop.secrets or whatever the virtual
package is called.

    smcv
    (not an Evolution maintainer)

This would indeed be very useful when using an alternative secrets manager,
like KeePassXC. If gnome-keyring is installed then it takes over the libsecret
d-bus interface and KeePassXC does not work properly.
I am using gnome-calendar in XFCE together with KeePassXC, so I need gnome-
keyring to stay out of the way. In fact, I can check that when I kill gnome-
keyring, so that KeePassXC is the libsecret provider, the syncronization of
calendars using the goa deamon retrieves the password from KeePassXC.

evolution-data-server which it definitely needs. So we can ignore the
part about evolution and just focus on evolution-data-server (which I
guess you somewhat realized since you did file the bug against the
right package.). Also, the "gnome" metapackage is irrelevant since
gnome-core depends on evolution-data-server. You don't need to have
evolution or "gnome" if you don't want to. I'd recommend keeping
"gnome-core" installed but that isn't required either; you just have
to handle making sure you have the components installed that you want.

Simon laid out a rough summary of the work needed here. Someone would
need to verify whether an alternate implementation fulfills all the
usecases that gnome-keyring does. If the verification succeeds, we may
want to introduce a virtual package to represent this.

I don't think anyone from the Debian GNOME team is working on this
project now so it's unlikely to happen in time for Debian 13 later
this year. It is a good idea to explore but the team is small and have
other priorities as we finish up Debian 13.

Thank you,
Jeremy Bícha

FYI, there is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124744 for bluez with a potential solution for this branch of dependencies
(splitting bluez-obexd-eds)