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
