Acknowledgement sent
to "Daniel Richard G." <[email protected]>:
New Bug report received and forwarded. Copy sent to أحمد المحمودي (Ahmed El-Mahmoudy) <[email protected]>.
Your message tried to set a usertag, but didn't have a valid
user set ('[email protected]' isn't valid)
Subject: Please include static library builds in libharfbuzz-dev
Date: Mon, 06 May 2024 17:51:39 -0400
Package: libharfbuzz-dev
Version: 8.3.0-2+b1
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.
Acknowledgement sent
to Jeremy Bícha <[email protected]>:
Extra info received and forwarded to list. Copy sent to أحمد المحمودي (Ahmed El-Mahmoudy) <[email protected]>.
(Mon, 12 Aug 2024 14:51:01 GMT) (full text, mbox, link).
Subject: Re: Please include static library builds in libharfbuzz-dev
Date: Mon, 12 Aug 2024 10:46:12 -0400
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
Acknowledgement sent
to "Daniel Richard G." <[email protected]>:
Extra info received and forwarded to list. Copy sent to أحمد المحمودي (Ahmed El-Mahmoudy) <[email protected]>.
(Mon, 12 Aug 2024 18:15:01 GMT) (full text, mbox, link).
Subject: Re: Please include static library builds in libharfbuzz-dev
Date: Mon, 12 Aug 2024 14:04:06 -0400
Hi Jeremy,
On Mon, 2024 Aug 12 10:46-04:00, Jeremy Bícha wrote:
> The vast majority of libraries packaged in Debian do not include .a files.
Most e.g. Rust library packages don't, sure. But normal C/C++ lib*-dev
packages typically include a static library.
> 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.
Indeed, this is a good use case for static 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
I am providing .deb packages of those applications for users who don't
want to deal with Snap or Flatpak. Including myself :)
> - 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.
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.
--Daniel
Acknowledgement sent
to Jeremy Bícha <[email protected]>:
Extra info received and forwarded to list. Copy sent to أحمد المحمودي (Ahmed El-Mahmoudy) <[email protected]>.
(Mon, 12 Aug 2024 19:27:01 GMT) (full text, mbox, link).
Subject: Re: Please include static library builds in libharfbuzz-dev
Date: Mon, 12 Aug 2024 15:21:34 -0400
On Mon, Aug 12, 2024 at 2:05 PM Daniel Richard G. <[email protected]> wrote:
> On Mon, 2024 Aug 12 10:46-04:00, Jeremy Bícha wrote:
> > The vast majority of libraries packaged in Debian do not include .a files.
>
> Most e.g. Rust library packages don't, sure. But normal C/C
++ lib*-dev
> packages typically include a static library.
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.
> 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.
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
Acknowledgement sent
to "Daniel Richard G." <[email protected]>:
Extra info received and forwarded to list. Copy sent to أحمد المحمودي (Ahmed El-Mahmoudy) <[email protected]>.
(Mon, 12 Aug 2024 21:30:02 GMT) (full text, mbox, link).
Subject: Re: Please include static library builds in libharfbuzz-dev
Date: Mon, 12 Aug 2024 17:25:24 -0400
On Mon, 2024 Aug 12 15:21-04:00, Jeremy Bícha wrote:
>
> 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.
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).
> 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.
Yes; my solution was to work around the missing static library, and
report the issue to Debian so that it can be fixed.
> Hopefully, you don't need to maintain support for older distros for
> very long.
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.
> 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.
It's all the same from my perspective...
> 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.
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.)
--Daniel
Acknowledgement sent
to Jeremy Bícha <[email protected]>:
Extra info received and forwarded to list. Copy sent to أحمد المحمودي (Ahmed El-Mahmoudy) <[email protected]>.
(Wed, 14 Aug 2024 12:33:02 GMT) (full text, mbox, link).
Subject: Re: Please include static library builds in libharfbuzz-dev
Date: Wed, 14 Aug 2024 08:31:03 -0400
On Mon, Aug 12, 2024 at 5:27 PM Daniel Richard G. <[email protected]> wrote:
> On Mon, 2024 Aug 12 15:21-04:00, Jeremy Bícha wrote:
> > 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.
>
> It's all the same from my perspective...
>
> > 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.
>
> 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
Acknowledgement sent
to "Daniel Richard G." <[email protected]>:
Extra info received and forwarded to list. Copy sent to أحمد المحمودي (Ahmed El-Mahmoudy) <[email protected]>.
(Fri, 23 Aug 2024 07:15:01 GMT) (full text, mbox, link).
Subject: Re: Please include static library builds in libharfbuzz-dev
Date: Fri, 23 Aug 2024 03:11:05 -0400
On Wed, 2024 Aug 14 08:31-04:00, Jeremy Bícha wrote:
>
> 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 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.
> 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.
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.
--Daniel