On Sun, 2024-01-07 at 18:23 +0300, Dmitry Shachnev wrote: > On Sat, Jan 06, 2024 at 07:50:47PM +0100, Ansgar wrote: > > Now try not to install an init system, dbus, ... in a application > > container wanting to use python3-poetry to install some Python > > application. > > > > And this still doesn't ensure that: > > 1. dbus is actually running in the context where python3-secretstorage is > > used, > > 2. the Dbus interface python3-secretstorage wants to talk to is actually > > provided by a service > > > > (For 2. it doesn't even have a Depends: gnome-keyring | alternatives > > either which is inconsistent with the dependency on Dbus...) > > 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. > > Also it's unknown whether that is actually useful or not (as python3- > > secretstorage is just a library that could not be relevant at all as > > the application's user might not actually want to manage secrets via > > keepassxc). > > > > It seems excessive to *always* require all of this to be installed for > > *any* use of python3-poetry (which can optionally use python3- > > secretstorage if that is even required). bash doesn't depend on gnome- > > terminal either just because one needs some terminal to run it in ;-) > > I think python3-secretstorage is completely useless without D-Bus. I think you miss my point: The dependency currently says "python3-poetry is useless without Dbus". > So maybe this dependency chain should be cut at a higher level, e.g. > between python3-keyring and python3-secretstorage. > > I am also the uploader of python3-keyring, so we can discuss it here. > > 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. Ansgar
