Packaging devel-only C++ library

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Packaging devel-only C++ library

Enrico Zini
Hello,

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
https://gitlab.eumetsat.int/open-source/PublicDecompWT

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?) ?


Enrico

--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <[hidden email]>

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packaging devel-only C++ library

Paolo Greppi
Hi Enrico,

see below.

Il 27/05/20 21:16, Enrico Zini ha scritto:

> Hello,
>
> 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
> https://gitlab.eumetsat.int/open-source/PublicDecompWT
>
> 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?) ?
>
>
> Enrico

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:
https://wiki.debian.org/Javascript/GroupSourcesTutorial
For C++ libs it does not make sense to use pkg-js-tools, so you'd go the manual
way.

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:
libmsat1 1.10.1+~2.7.2

Here is a bundling example with extreme version string:
https://tracker.debian.org/pkg/node-debbundle-es-to-primitive

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:
https://tracker.debian.org/pkg/node-yarnpkg

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.

Paolo

Reply | Threaded
Open this post in threaded view
|

Re: Packaging devel-only C++ library

Tomas Pospisek ML
In reply to this post by Enrico Zini
On 27.05.20 21:16, Enrico Zini wrote:

> Hello,
>
> 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
> https://gitlab.eumetsat.int/open-source/PublicDecompWT
>
> 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?) ?

I'm not sure why you wouldn't want to package it as a separate library,
apart from maybe this being more work. I think it doesn't hurt Debian to
have one more package. OTOH clean modularization usually has very strong
benefits, which would be an argument for packaging it separately.

My 2 cents,
*t