It is customary for -dev packages to provide static archive libraries in
addition to the bare .so files for shared-library linking. The current
version of libharfbuzz-dev only provides the latter, and thus does not
allow applications to statically link the libraries.

I understand that GObject introspection requires a shared-library build,
but this functionality is often not needed. In particular, the Chromium
browser consumes harfbuzz and harfbuzz-subset, and does perfectly well
without introspection support. I recently ran into a situation on the
Ubuntu side of things where the lack of a static-linking option caused
some difficulty in supporting Chromium on 22.04/jammy:

https://bugs.launchpad.net/bugs/2064821

My solution was to produce a modified harfbuzz package that provides
(only) static libraries:

https://launchpad.net/~xtradeb/+archive/ubuntu/deps/+sourcepub/16120809/+listing-archive-extra

Needless to say, it would be preferable if the official packages
supported static linking from the get-go.

The vast majority of libraries packaged in Debian do not include .a files.

It sounds to me like your real issue is that you are attempting to use
newer libraries on a distro that doesn't provide those libraries. You
have some additional options beyond the workaround you implemented:

- Encourage your users to switch to Snap or Flatpak for much easier
dependency handling for older distros. This is what Canonical did with
Firefox, Chromium, and Thunderbird
- Also package the libraries you need in a PPA or similar repository.
This is a bit more complex to handle the initial user install. You're
also responsible for providing security support for the library.
Hopefully, it doesn't interact badly with the rest of the system. It
could cause users difficulties on upgrading to new versions of their
OS.

Thank you,
Jeremy Bícha

Hi Jeremy,

Most e.g. Rust library packages don't, sure. But normal C/C++ lib*-dev
packages typically include a static library.

Indeed, this is a good use case for static libraries.

I am providing .deb packages of those applications for users who don't
want to deal with Snap or Flatpak. Including myself :)

My goal is to provide the application, not the library. As you can see,
providing the library generally would be a much bigger/riskier deal than
just using it as a build-dep.

++ lib*-dev

No, they don't. There definitely are several C libraries that do
include a static library in Debian, but most of the C libraries I
maintain do not.

It's going to be a bit painful to try to use a newer/different system
library than provided by the system if you're not going to use a
sandboxed approach. However, it sounds like you figured out a working
solution. Hopefully, you don't need to maintain support for older
distros for very long. In this case, it's not that you need a new
library; it's that Debian didn't enable the subset feature earlier.
Sorry about that.

Sorry, I don't see enough demand for harfbuzz to be distributed as a
static library for me to make that change in the Debian packaging at
this time.

Thank you,
Jeremy Bícha

Of the 57 lib*-dev libraries that chromium lists in its Build-Deps, all
of which appear to be C/C++ libraries, 19 do not have lib*.a libraries.
And only two are of concern with my builds (harfbuzz and dav1d).

Yes; my solution was to work around the missing static library, and
report the issue to Debian so that it can be fixed.

How long is jammy being supported? As long as I don't have to provide
half the world as build deps, that would be the ideal.

It's all the same from my perspective...

What kind of quorum are you looking for? It's not like this package gets
much in the way of bug reports in general, after all. I think I've made
a reasonable case for including a static build.

(If you want to argue that this package is complex enough that adding a
static build is a fair amount of work, then that's a different story,
of course.)

I think it would be as simple for you as to build the harfbuzz package
with this addition to the dh_auto_configure build-main line:
--default-library both

And then add the .a file to debian/libharfbuzz-dev.install

Since you already have to build harfbuzz yourself to get the subset
library, I think you should just make that change to your harfbuzz
package.

I don't see a need to make a change to the current Debian packaging to
fix an issue that doesn't actually exist in Debian Unstable/Ubuntu
24.10. The real issue is that the subset library isn't built for older
distros but it is built for current distros.

Thank you,
Jeremy Bícha

I made a similar change (enabling only the static library) and built the
package myself out of immediate need. But the point of Debian is to be a
distro, not Linux From Scratch.

There are two reasons aside from that immediate need for which I've
filed this bug:

1. Avoiding the need to modify the package. This may not sound like
   much, but in the context of supply-chain tampering and
   vulnerabilities, being able to use Debian's vetted source verbatim
   simplifies the review process considerably;

2. Taking a step toward being able to produce a Chromium binary
   build for jammy that will also run on noble (where an ABI-
   compatible library is not available). This is why libdav1d-dev is
   also a concern.

Debian software would not be very useful if it were limited to solving
problems within Debian. Static libraries lend themselves to a number of
use cases, which include overcoming limitations of the packaging.