Re: Bug#927725: Please build with --enable-mmdblookup

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Bug#927725: Please build with --enable-mmdblookup

Michael Biebl-3
Am 23.04.19 um 10:32 schrieb Michael Biebl:

> 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
(dependency wise).

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 [1].

But splitting each tiny module into a separate package adds significant
overhead packaging-wise.

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
rsyslog-extras package.

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.

Seeking for input on debian-devel.

Regards,
Michael


[1] https://tracker.debian.org/pkg/rsyslog
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug#927725: Please build with --enable-mmdblookup

Michael Biebl-3
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)


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug#927725: Please build with --enable-mmdblookup

John Goerzen-3

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.

John

Reply | Threaded
Open this post in threaded view
|

Re: Bug#927725: Please build with --enable-mmdblookup

Anthony DeRobertis
In reply to this post by Michael Biebl-3
On 4/23/19 5:12 AM, Michael Biebl wrote:
>
> My main concern is to keep the rsyslog core package reasonably small
> (dependency wise).


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.

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

Reply | Threaded
Open this post in threaded view
|

Re: Bug#927725: Please build with --enable-mmdblookup

Sam Hartman-3
In reply to this post by John Goerzen-3
>>>>> "John" == John Goerzen <[hidden email]> writes:

    John> 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)

    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
them.

--Sam

Reply | Threaded
Open this post in threaded view
|

Re: Bug#927725: Please build with --enable-mmdblookup

Guillem Jover
In reply to this post by Anthony DeRobertis
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 | Threaded
Open this post in threaded view
|

Re: Bug#927725: Please build with --enable-mmdblookup

Guillem Jover
In reply to this post by John Goerzen-3
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.

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

Re: Bug#927725: Please build with --enable-mmdblookup

Dmitry Smirnov
In reply to this post by Michael Biebl-3
On Tuesday, 23 April 2019 7:12:17 PM AEST Michael Biebl wrote:
> Maybe it would even make sense to fold rsyslog-relp, rsyslog-gnutls and
> rsyslog-gssapi into this rsyslog-extras package.

I'd say that IMHO relp should be in the core package. I always have it on all
my machines and it is the most used/useful extension for centralized logging.

--
Regards,
 Dmitry Smirnov.

---

If liberty means anything at all, it means the right to tell people what
they do not want to hear.
        -- George Orwell

signature.asc (849 bytes) Download Attachment