Re: Bug#927725: Please build with --enable-mmdblookup
On Wed, 2019-04-24 at 04:39:50 -0400, Anthony DeRobertis wrote:
> On 4/23/19 5:12 AM, Michael Biebl wrote:
> > My main concern is to keep the rsyslog core package reasonably small
> > (dependency wise).
I think either a new package for this plugin or a conglomerate package
with extra stuff sound good. Also nothing says there cannot be both,
say based on expected use or size of pulled dependencies.
> If you check <https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends>,
> note that a Depends is only required if "the depended-on package is required
> for the depending package to provide a significant amount of functionality".
> That, taken together with the tools typically installing Recommends by
> default, means you can make the libraries Recommends, not Depends. Or maybe
> even as Suggests.
>
> Ideally, rsyslog would give a nice error if it fails to load a plugin due to
> a missing shared library, but even without that you can just mention needing
> to install Recommends and/or Suggests to use various optional plugins in the
> package extended description, README.Debian, etc.
I don't think this is well suited at all for plugins. The failure mode
of a missing shared library is actually the nice one, the real problem
here is if there's some kind of versioned ABI dependency (not represented
via versioned symbols), which might make the plugin load but misbehave
afterwards.
Conditional loading of external shared libraries is not a very robust
way to integrate software. When upstreams go to the trouble of doing
it properly via plugins (as is the case here), the split boundary for
such plugins should really always be the plugins themselves (if a
split is desired at all), because the program has intimate knowledge
about the ABI between itself and its plugins.
That policy section might deserve some clarification too.
Thanks,
Guillem
Reply to: