Den 2026-10-08 kl. 16:16, skrev John Scott:
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).🙷
I saw the discussion - and I saw the issue when packaging Skia ~6 months
ago. The error message says "The Skia team is not endian-savvy enough to
support big-endian CPUs...", which to me reads in line with your
understanding, perhaps in combination with a lack of regular testing on
big-endian machines.
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.
This is sadly in line with the recommendations from upstream. The tone
is essentially: link it statically with your program. At least they do
have build options for shared libraries, but I needed to tweak them a
bit to give the .so file a proper soname, which indicates that
system-wide installation may be a bit of an afterthought.
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.)
You are right, they recently switched to a bi-weekly release schedule
(which is one thing that made me re-think the situation). I suppose they
have not updated that page yet.
As for API stability: the milestones are very stable (only backporting
high-priority patches), but that does not matter too much as they are
only active for two weeks. As upstream for storm-lang (the other user of
libskia), I have updated the Skia version 2-3-times by now. Each time
about a year of releases. Most parts of the API are the same, but each
time there have been some (relatively small) details that I needed to
change. For example, gradient fills moved from one place to another, and
later changed what color parameter they received (to be explicit about
color spaces, I think). A bit annoying, but small patches at the end of
the day (I carried one such patch in storm-lang in Debian for a while).
That being said, I think I am using a relatively small portion of the
API there.
I am not familiar with the libxml2 situation, so I cannot say too much
about it. My experience is that the API on a source level is
well-designed enough to break when details are changed, so I am not
worried about version mismatch causing issues. Given that it is C++,
binary compatibility across such changes is another thing (e.g. removing
a virtual function may cause vtables to mismatch). This is why I use the
milestones for the so-version. Both the API and ABI are stable across
milestones, but this will of course lead to more frequent soname bumps.
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.
Thank you for these thoughts - after reading them, I think they are a
good summary of my own feelings as well. The high pace of development
and CVEs makes it difficult to keep up. It is a bit sad - Skia is
otherwise a good library. The reason I ended up with it for storm-lang
was that I did not find any other hardware-accelerated 2D rendering
library that fulfilled my needs at the time, and Skia seemed to be
recommended almost as a de-facto standard. It seems skia-pathops is in a
similar position, at least in some areas.
Thanks also for the note about boundaries. I think I was aiming a bit
too high initially, especially given the importance of security work. I
was in contact with Moritz (jmm) from the security team about this, and
we ended up with something like your suggestion: providing libskia
without security support for cases where that is acceptable (they were
fine using it for storm-lang also, which is the main reason I packaged
it initially).
(On a positive note, this entire situation inspired me to sketch out a
custom OpenGL-based 2D renderer for storm-lang based on ideas from
nanovg. It ended up being a quite fun thing to do! Maybe it will even be
good enough to ship someday.)
Greetings,
Filip
