Re: Packaging devel-only C++ library
Il 27/05/20 21:16, Enrico Zini ha scritto:
> I'd like to package a new version of https://github.com/ARPA-SIMC/meteosatlib,
> for which I'm upstram, which depends on the recently freed
> PublicDecompWT is a C++ development-only library released by Eumetsat,
> with functions needed to decompress MeteoSat images. Historically it has
> had a relatively stable API, but no guarantees are made about an ABI as
> far as I know, and to make matters worse ABI-wise, it's C++.
> These options come to my mind:
> - use git submodules and pull PublicDecompWT into meteosatlib, in a way
> slightly more convenient to the current instructions of obtaining the
> zipfile from eumetsat and putting it there
> - package PublicDecompWT as a devel-only library in Debian, and
> build-depend on it for meteosatlib.
> Suggestions? Other ideas? Special things to keep in mind in cases like
> this (Built-Using?) ?
In this case I'd go for bundling the sources together.
You can add a Provides: libPublicDecompWT-dev in debian/control just in case
someone else ever needs it.
Convincing ftp-master that this is OK is left as an exercise.
To bundle, in js-team we quite a lot the "group sources" technique:
For C++ libs it does not make sense to use pkg-js-tools, so you'd go the manual
You can optionally track component version in package version so that uscan
follows all the changes, but then you get the famous funny version strings.
I.e. if your main package is called libmsat1 and is at version 1.10.1 and you
choose to bundle with it PublicDecompWT version 2.7.2 you get:
Here is a bundling example with extreme version string:
If the version of the embedded dependency is stored somewhere in the main
package source, so that it can unambiguously be inferred, you can do without
tracking component version(s). Here is a bundling example with no tracking:
In this latter example the file yarn.lock has the list of all dependencies,
so the main package version is enough to infer all the components versions.