[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: post-jessie: header only C++ library package (static?)


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.



Reply to: