On Sun, Jan 07, 2024 at 07:31:48PM +0100, Ansgar wrote: > > gnome-keyring | alternatives is in Recommends, not in Depends. > > > > The reason for that is because someone may want to use secretstorage > > with a different server that is not listed there, and we do not have a > > virtual package name that any such implementation can provide (like e.g. > > notification-daemon is provided by 14 different packages). > > So will you add a virtual package and a strict dependency? AFAIU it is > about as uesless without one of these providers as it is without Dbus.
I think you really don't want it to be a strict dependency, do you? > > I can suggest two solutions: > > > > 1. Replace python3-keyring → python3-secretstorage Depends with Recommends. > > 2. Keep it Depends, but add some alternatives, e.g. python3-secretstorage > > | python3-keyrings.alt. > > > > Will any of that work for you? > > I think that is still fundamentally wrong. > > A program X linking a library (classic C libraries or python3-* stuff; > implementation doesn't matter) will result in a relation "X depends > libY". > > But that doesn't say anything about if users actually will use "libY". > > For example, consider libY as a library speaking to Pulseaudio, libZ a > library speaking to jack2d. The application X now links libY and libZ > as it has support for audio output via libY or libZ; it can also output > audio via ALSA. > > Installing X thus installs libY and libZ. > > Clearly libY is useless without PA and libZ useless without Jack in the > same way as python3-keyring is useless without Dbus + Secret Service > backend. > > Should libY thus depend on Dbus + Pulseaudio and libZ depend on jackd? > That would result in a user wanting to install X having to install > Dbus, Pulseaudio and Jack. That is in particular two audio servers > that will then be enabled by default. > > As Debian tries to build packages with as much optional stuff as > possible enabled, this would happen very often (we have more sound > servers...). > > Is that useful? I think not and think libraries *must not* depend on > services for that reason. If soemthing explicitly depends on a service, > it should be an application, not some library. Your analogy doesn't 100% apply to Python world. In C, if you link to some library, your application won't start when that library is not installed. However, in Python, it's quite easy to make imports optional. And Keyring does exactly this, "import keyring" will not fail if python3-secretstorage is not installed. So, if some users of python3-keyring don't need python3-secretstorage, we can make it Recommends, not Depends. Similarly, I see that poetry imports keyring not on the top level, but in the code where it's actually needed [1], and poetry will start when keyring is not installed, so maybe poetry should Recommend python3-keyring, not depend on it. But anyway, if you insist that python3-secretstorage should not depend on dbus-related packages, I can demote that to Recommends. For most users that shouldn't make any difference because we have Recommends enabled by default. Will that work for you? [1]: https://sources.debian.org/src/poetry/1.7.1%2Bdfsg-1/src/poetry/utils/password_manager.py/#L48 -- Dmitry Shachnev
signature.asc
Description: PGP signature
