Draft: Build-Depend on unicode-cldr-core and drop Unicode missing-source
@smcv Although not directly used by the gtk4 build, unicode-cldr-core is approximately the source data for emojibase.
Technically emojibase is using cldr-json which is not yet packaged in Debian.
Then, drop the copy of the Unicode data from debian/missing-sources/
We could optionally add a Build-Depends: unicode-data (>= 15.1) but I am leaning towards not.
Merge request reports
Activity
Although not directly used by the gtk4 build, unicode-cldr-core is approximately the source data for emojibase
My concern is that if we do this, in a few months someone with a sufficiently uncompromising opinion on preferred forms for modification will say: "but now unicode-cldr-core has been upgraded to version x and GTK still has files derived from version y < x, therefore GTK is RC-buggy again", and we'll be on the hook to fix it, under the threat of having half the GUIs in Debian removed.
I think unfortunately we do need to use either
missing-sources(as here), or an extra orig tarball (as in gobject-introspection's copy of glib2.0 or glib2.0's copy of the Unicode data).
"but now unicode-cldr-core has been upgraded to version x and GTK still has files derived from version y < x, therefore GTK is RC-buggy again"
Wouldn't it be the same as statically linking a library? And would a reply along the lines of "don't worry, things will be ok once we rebuild gtk4"? Or am I misunderstanding this?
-
That logic would work if we were actually rebuilding the emoji data from first principles every time, but we are not; we're using the emoji data pre-generated by upstream (which is human-readable and human-editable, but directly editing it is not encouraged), and also shipping (what we hope is) its ultimate source code in order to placate contributors with a sufficiently uncompromising definition of the preferred form for modification.
If we did rebuild the emoji data every time, I think there'd be a serious risk that GTK would fail to build from source with a newer or older set of emoji source data than the one upstream used, and that when we reported that to upstream and asked for help, we would simply be told that we were wrong to attempt to regenerate it and should stop doing weird Debian things.
(I already feel as though I'm one step away from being banned for being an inconvenience every time I report a test failure on a non-x86 architecture, so I'm reluctant to increase friction with upstream and make myself more of a scapegoat for Debian's decisions.)