Re: Question about library package splitting
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.
Reply to: