Hi! * Valentin Vidic [Thu Oct 17, 2024 at 03:12:59PM +0200]: > On Thu, Oct 17, 2024 at 12:03:26PM +0200, Michael Prokop wrote: > > And the package does *not* depend on all available fence agents, > > they are only recommends. > > > > I'm aware that folks disabling Recommends are supposed to know what > > they are doing. But at least in my experience avoiding Recommends is > > a common practice esp. amongst server systems where fence-agents has > > its use case. And if someone is upgrading fence-agents from bookworm > > (v4.12.1-1) to trixie (v4.15.0-3) and isn't aware of this > > fence-agents Recommends situation *upfront*, the system will end up > > with this empty / broken fence-agents situation. > > Right, the split was done exactly to benefit server systems so they > don't have to install 1GB of dependencies for agents they don't use.
fence-agents on plain bookworm is 216 MB including all its dependencies, but I get what you're saying and agree. :) > > IMO the fence-agents should: > > > > a) at least depend on fence-agents-common, and: > > Not sure how this helps with the transition? This is a common library > and most agents depend on it directly. I would assume that someone installing fence-agents for sure also wants to always have /usr/lib/tmpfiles.d/fence-agents.conf then? Also /usr/share/fence/fencing.py is essential for anyone writing their own / custom fence agents (as it has been observed in the customer's environment where I ran into this issue). If someone has fence-agents present on bookworm and updates the system without Recommends, even such custom fence agents would break then if /usr/share/fence/fencing.py isn't available then, since fence-agents doesn't depend on fence-agents-common. Really no hard feelings from my side (since one can then depend on fence-agents-common once you're aware of it), but it feels like this is asking for upgrade troubles in trixie to me. Or to put it different: would there be any actual drawback in depending on fence-agents-common within fence-agents? *hmmm* > > b) a "fence-agents-all" package which *actually* depends on *all* > > agent packages could further mitigate this situation (the > > fence-agents package itself then could use fence-agents-all in its > > Recommends). > > Would it be better for fence-agents-all to replace fence-agent than? That could be worth a thought, yes. Having a good upgrade path even for users without Recommends enabled, but at the same time also having the option to install only *certain* fence-agents is definitely a worthwhile goal. :) regards -mika-
signature.asc
Description: PGP signature
