On Thu, 2026-09-24 at 08:44 +0200, Filip Strömbäck wrote: > One option would be to drop it. Since the package is fairly new, the impact > is not too large (but still sad, the fonts-team uses skia-pathops to build > some fonts).
You may already be aware but it deserves an explicit mention: WebKitGTK now requires the use of Skia for graphics. And if the words "WebKitGTK" and "Skia" together are giving anyone déjà vu, that's because of the recent debian-devel thread "WebKitGTK and architecture support in Debian". ◦ As an aside, the reason that Skia isn't portable isn't due to a genuine constraint, but to my understanding, it's simply because the code was written to correspond to little-endian byte ordering when "type punning" or manipulating the in-memory representation of various data types. Such problems have been well-known since antiquity and is a sign of poorly-written code, which wouldn't be a big deal if folks at Google were to care. See UNIX Network Programming (Third Edition, by W. Richard Stevens et al) page 80 for example: 🙶A common network programming error in the 1980s was to develop code on Sun workstations (big-endian Motorola 68000s) and forget to call any of these four functions [htons(), htonl(), ntohs(), ntohl()]. The code worked fine on these workstations, but would not work when ported to little-endian machines (such as VAXes).🙷 Anyway, here are a couple important details about WebKitGTK and what it means for us: ‣ WebKitGTK is supported in Debian stable releases by providing new stable releases as needed, but it's a big undertaking and a miracle that the maintainers and security team were able to make this work at all. ‣ Currently WebKitGTK uses an embedded code copy of Skia as provided in the WebKitGTK releases, so it doesn't use your proper libskia package at all. In fact WebKitGTK doesn't even have a build option to try using a system copy, but I've filed a request at https://webkit.org/b/320369 to make the desire known. The latter bit adds an extra degree of freedom. What's the ABI stability of Skia like? Is it susceptible to Heisenbugs at the worst possible time (like libxml2...) or is it just as reasonable as usual for other packages to depend on the libskia package? I see libskia is available as a shared library which makes me optimistic about the latter. On the other hand https://skia.googlesource.com/skia/+/refs/heads/main/RELEASE_NOTES.md does show such changes as function removals. I see https://skia.org/docs/user/release/ says > We recommend most clients track our tip-of-tree as we work hard to keep it > green. [...] > If you require less frequent updates, we cut a stable milestone every four > weeks along with Chrome. > Chromium (and Skia) have a staged branching strategy. Every four weeks a > branch is cut from a relatively stable revision near HEAD, is stabilized for > six weeks, and then promoted to stable. (Is that still accurate? At https://chromiumdash.appspot.com/schedule it hints Chromium could be on a biweekly schedule now.) In conclusion, I recognize there are difficult social factors at play. I am concerned about consequences for the free software movement with respect to fast-moving, "take it or leave it" projects (and I don't assert that Skia is one, but that's where my thoughts are headed so far). When code changes so frequently that no one who *isn't* a full-time employee of the producer can wrap their head around it, this creates some practical friction with the freedom to modify, share, and use the software. The challenge of keeping up with security issues for you could be an example. I don't have any idea what motivates you to work on the Skia package. Take care of yourself and set a boundary as you see fit: you owe no one an explanation for how you choose to spend your time contributing. If that means providing the libskia package primarily just for skia-pathops and asserting there is no security support, that'd be quite sensible.
signature.asc
Description: This is a digitally signed message part
