On Tuesday, December 2, 2025 3:02:45 PM Mountain Standard Time Soren Stoutner wrote: > On Tuesday, December 2, 2025 1:27:02 AM Mountain Standard Time Alastair > > McKinstry wrote: > > Hi > > > > I would like to plan a transition for unicode-data 16.0.0 -> 17.0.0 > > > > Version 17 is now in experimental, and by design this *should* be a > > trivial upgrade: the package ships tables of data that should be > > extended only, no drop in functionality or change in format. > > > > However see #1113798, a transition is preferred as strict version > > locking in some packages (notably utf8proc) causes issues. > > > > I would appreciate advice on how to do this. Some packages have > > "Build-Using: " metadata on unicode-data: > > > > $ grep-aptavail -F Built-Using -s Package,Built-Using -r 'unicode-data' > > > > reveals: > > courier-unicode > > I am the maintainer of courier-unicode. I asked upstream if he anticipated > that building against 17.0.0 would cause any problems. > > https://github.com/svarshavchik/courier-libs/issues/52 Upstream responded (in part): "More subtle differences are also possible. The code might still compile but be non-compliant with the standard. Let's say that Unicode 17 includes changes to the line-breaking or the bi-directional algorithm (the logic that uses LineBreak.txt and various Bidi txt files). I don't know if it does or not, I haven't looked yet. They don't change in every release but they do change, from time to time. If so, this will require a code change. The algorithm change might also involve a related change to the data files, which might not be severe enough to result in a compilation failure. Everything will continue to compile but without the corresponding logic changes the end result will not comply with the standard. Making things even more interesting is that LineBreak and Bidi might remain unchanged, from standard to standard, but there's a new revision of the corresponding algorithms, so you can't always tell just by comparing the files.” Looking over the list of affected packages, I suspect that not all of them will have upstream support for unicode-data 17.0.0 at the same time. My recommendation is that, during transitions, we maintain two version of unicode-data in Debian, one for the old version and one for the new version. -- Soren Stoutner soren@debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part.