This will add a runtime dependency on libmaxminddb0 and I'm not sure
everyone will be happy with that as this is a rather uncommonly used
library and thus not installed by default.
Splitting out this tiny module seems like a lot of overhead.
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
> Am 22.04.19 um 03:11 schrieb Dmitry Smirnov:
>> Source: rsyslog
>> Version: 8.1901.0-1
>> Severity: wishlist
>> https://www.rsyslog.com/doc/v8-stable/configuration/modules/mmdblookup.html >>
>> Enabling "mmdblookup" requires adding "libmaxminddb-dev" to Build-Depends.
> This will add a runtime dependency on libmaxminddb0 and I'm not sure
> everyone will be happy with that as this is a rather uncommonly used
> library and thus not installed by default.
> Splitting out this tiny module seems like a lot of overhead.
My main concern is to keep the rsyslog core package reasonably small
Up until now, I've split modules with larger dependencies into separate
subpackages, mostly the ones which target specific database backends,
like rsyslog-mysql, rsyslog-pgsql etc .
But splitting each tiny module into a separate package adds significant
If I take rsyslog-relp as an example, the actual .so is around 76K, the
packaging meta data, 270K.
Maybe a middle ground would be to build a rsyslog-extras binary package
which contains all sorts of modules which have additional
library/runtime dependencies that I don't want to pull into the rsyslog
package or are less well tested/maintained upstream.
Maybe it would even make sense to fold rsyslog-relp, rsyslog-gnutls and
rsyslog-gssapi into this rsyslog-extras package.
The binaries packages which target specific databases I would probably
keep as separate binary packages.
But e.g. this module (mmdblookup) would be a candiate for such a
Not quite sure what users of rsyslog would want regarding the
granularity of the packaging, i.e. if they'd be happy with such a single
rsyslog-extras package, if they actually wouldn't mind if such modules
would be added to the rsyslog binary package itself (and the additional
runtime dependencies), or if they'd prefer separate binary packages for
each module if it has additional runtime dependencies.
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.
(Of course, this does make the packaging a bit more complicated, since
you'll need to add some -d options to your dpkg-shlibdeps call. Probably
easier than even more extra packages, though.)
>> Am 23.04.19 um 11:12 schrieb Michael Biebl:
>>> But splitting each tiny module into a separate package adds
>>> significant overhead packaging-wise.
>> (not to forget NEW round trips)
John> What about an approach like exim4-daemon-light
John> vs. exim4-daemon-heavy? Maybe have two rsyslogs, one of which
John> has all the deps enabled and the other doesn't.
Speaking entirely as an individual only vaguely familiar with the
situation. I think that for rsyslogd a -extras package makes more
sense. I don't think the deps have much of a cost if you don't install
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
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.
On Tue, 2019-04-23 at 19:35:50 -0500, John Goerzen wrote:
> On Tue, Apr 23 2019, Michael Biebl wrote:
> > Am 23.04.19 um 11:12 schrieb Michael Biebl:
> >> But splitting each tiny module into a separate package adds significant
> >> overhead packaging-wise.
> > (not to forget NEW round trips)
> What about an approach like exim4-daemon-light vs. exim4-daemon-heavy?
> Maybe have two rsyslogs, one of which has all the deps enabled and the
> other doesn't.
I don't think this makes sense here, as following the exim example
would seem to imply shipping the rsyslog binary twice, which is not
necessary as it supports actual plugins compared with exim.