Re: post-jessie: header only C++ library package (static?)
Hello,
On 18 October 2014 17:19, Osamu Aoki <osamu@debian.org> wrote:
> Hi,
>
> This is about packaging around a header only C++ library package.
>
> As I understand, Debian does not usually ship static libraries based on
> policy "8.3 Static libraries". At the same time, Debian does not impose
> any systematic way to let us trace upload of the static library and
> alike.
> https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static
>
> I happen to read Fedora Packaging guideline on this topic and found out
> that they enforce to package static libraries in a separate *-static
> package. So whenever a *-static is updated, they can trace and rebuild
> packages build-depending on such a *-static package.
> http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries
>
> Since we expect practically all programs should not link to the static
> library, I thought that the Debian situation is not too bad. I thought
> that we should be able to manage situation with rare cases of bin-NMUs
> for some special packages.
>
> Then I saw "Packaging Header Only Libraries" for C++.
> http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Header_Only_Libraries
> | Certain libraries, especially some C++ template libraries, are header
> | only libraries. Since the code is generated during compile time, they
> | act just like static libraries and need to be treated as such.
>
> Fedora forces such library to use package name *-static to let all
> packages depending on it be traced (and rebuild as needed). It also
> requires such seemingly arch=all (in the Debian term) packages to be
> marked arch=any (in the Debian term).
>
> "header only C++ library package" seems to be more common.
>
> Do we have some mechanism to track such situation?
>
> If we don't, maybe we should have similar rules.
>
A large portion of boost is static only libraries. Similarly STL comes
to mind as well. The danger in those are transitive API/ABI breaks,
e.g. whilst compiling foo against newer template works, it becomes
API/ABI incompatible with foo build against older template version.
This is in part, why each new boost release is packaged with new
name-versioned packages in debian.
I don't believe we consistently binNMU packages that build depend on
templates only, simply by virtue that they are not caught/tracked by
the binary transition tracker (or the auto-generator of thereof).
Automatic API/ABI tracking should help here, as presented by me at
Debconf 2014, but I haven't yet set that up.
--
Regards,
Dimitri.
Reply to: