Splitting collectd dependencies [Was: Re: Another take on package relationship substvars]
None of this is relevant to the substvars discussion, but the collectd
side is worth looking at on its own.
On Sat, Feb 24, 2024 at 01:36:33PM +0100, Gioele Barabucci wrote:
> On 24/02/24 11:26, Bernd Zeimetz wrote:
> > Absolutely. collectd for example - otherwise you would install *all*
> > plugin dependencies with collectd, which would be a big waste of space.
> >
> > The other option would be to make one packe per plugin as redhat does,
> > but do we really want 20 packages with a single file?
>
> Yes, please. So that installing package collectd-foo ensures that all the
> required dependencies are installed, instead of having to hunt them down (a
> task better left to the package maintainers rather than the end users).
There is a balance to be struck here. Adding one package per plugin is a
lot of plugins and you often install multiple plugins together. It is
not obvious that the benefit of splitting is worth the associated cost.
I think there is a middle ground here. Having one package per plugin
definitely does have advantage. However, consider the option of turning
those packages virtual. So you'd have tons of collect-plugin-foo
packages provided from collectd initially. Then, multiple plugins tend
to use the same dependencies and some plugins tend to use no additional
dependencies. The latter can just be left in the main package together
with their provides. The former can be grouped together to say
collectd-plugins-hardware or something that you wouldn't want on a
virtual machine. Together with the plugins, you'd also move the provides
and recommends (maybe upgraded to depends then). In particular, you can
later restructure the plugins provided that downstreams only depend on
your virtual collect-plugin-* packages rather than the underlying
physical packages.
An example where this has successfully been implemented with Depends and
a small installation footprint is lighttpd.
Helmut
Reply to: