Bug#1085256: fence-agents: fence-agents package does not depend on any actual package

[Valentin Vidic]

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.
Not sure how this helps with the transition? This is a common library
and most agents depend on it directly.

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?

[Michael Prokop]

Hi!

Post by Valentin Vidic

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. :)

Post by Valentin Vidic
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*

Post by Valentin Vidic

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-