Hi Guillem,
first of all, many thanks for your answer! And sorry for my late reply... On Sat, Sep 07, 2024 at 02:46:13AM +0200, Guillem Jover wrote: > On Fri, 2024-09-06 at 11:32:55 +0200, Ervin Hegedüs wrote: > > 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. yes, that's a possible solution - I'm going to check that option. > > 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. yes, exactly. > > 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. yes, but the two package will install a shared object with same name. Or I don't see the point here. > 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. right, > 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». right, thanks, > > * are the names acceptable "libmodsecurity3t64" and > > "libmodsecurity3-lmdbt64"? > > The t64 suffix for the lmdb one should not be needed. okay, > > * 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 for these too. I'm going to investigate how can we change/add a feature to select the backend after installation, and if it's too complicated, then I try to split the package. Many thanks again! a.
