Hi!

On Fri, 2024-09-06 at 11:32:55 +0200, Ervin Hegedüs wrote:

Here comes the problem: libmodsecurity3 has two types of collection stores: in-memory and LMDB. It's VERY important: you MUST decide the type of
choosed backend in compilation time, later you can't change it in runtime!

I think ideally upstream would be modified so that this decision can
be made somehow at runtime? Then most of the problem presented goes
away.

If you choose the in-memory storage, you will lose your stored data when
you restart the web server, but it does not need any dependency.

I initially thought the libmodsecurity library would contain minimal
to no dependencies, where avoiding the lmdb one would then make sense,
but checking now, it has lots of dependencies, so this does not seem
like a very strong argument.

I don't want to force users to use LMDB, rather I prefer to deliver two library packages: one with in-memory and one with LMDB.

See above about making this a run-time selection. But if this is not
feasible or upstream does not want to go that way, the problem I see
is that selecting how the library behaves then becomes a system global
binary selection of behavior, depending on what implementation is
installed. Also this does not seem very user friendly, as shared
libraries tend to be just dependencies one does not need to care of,
as these get pulled automatically by whatever might need them.

I guess though there is some small precedent that I know of in Debian
with for example the ffmpeg libraries such as libavcodeN and
libavcodec-extraN and similar, or the multiple libblas.so.N and
liblapack.so.N implementation providers.

I couldn't find any guideline in Debian packaging documentation but found
the libcurl-dev as a pattern.

I think this is somewhat different, as these are co-installable, and
whether to use one or the other is selected by the package using it
at build time, not by the user.

Based on that I created a simple test package to emulate the behavior (compiling libmodsecurity takes more time - this package is very simple and anyone can build few seconds):

https://salsa.debian.org/airween/testlib/

Before I send the modified package structure, I would like to ask few questions:

Even with the above, if you still want to go in this direction:

* in this case the API hides the differences between two solutions; Is it enough to make one -dev package and two different runtime packages?

Given that this seems to be an implementation detail and supposedly
neither the API nor ABI change, and this seems to be intended as a
mechanism for the *user* to select the implementation, and not the
package linking against it to select it, then I think a single -dev
package would be better.

In this case how to allow switching implementations can be done either
via Provides+Conflicts+Replaces; or Conflicts+Replaces and then making
the symbols or shlibs file generate dependencies on both library as alternatives such as «libfoo | libfoo-lmdb».

* are the names acceptable "libmodsecurity3t64" and "libmodsecurity3-lmdbt64"?

The t64 suffix for the lmdb one should not be needed.

* based on the test package, are there any comments or advice to be considered?

Some passing and non-exhaustive packaging comments:

- autotools should support out-of-tree builds, so there should be no
need to copy the source tree into a subdirectory, just creating the
subdir and calling ../configure should do.
- you can use execute_after_ or execute_before_, instead of duplicating
the dh calls.
- you do not need the .dirs fragment files, as the .install ones
should take care of creating the needed directories.
- debian/compat is deprecated, you can use debhelper-compat (= 13)
instead.
- if you are going to support omitting specific packages per
build-profile, then you should add a Build-Profile field to the
relevant binary packages, so that they do not get built at all,
and then also annotate the lmdb build dependency, although this all
seems a bit excessive?

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)