shared libraries [ no longer specific to either Rust or Fedora ]

Posted Oct 31, 2022 21:31 UTC (Mon) by sfeam (subscriber, #2841)
In reply to: Packaging Rust for Fedora by Cyberax
Parent article: Packaging Rust for Fedora

Two examples I am still tracking because up- or down- grading from their current distro version is the best advice I can give to users who report problems.

font handling:

libpango 1.43 - good
libpango 1.44 - bad
libpango 1.45-47 - ? (did not see any reports for these versions)
libpango 1.48 - good

numerical library:

libcerf 1.7 - good
libcerf 1.8 - 1.10 - (bad convergence)
libcerf 1.11 - good

shared libraries [ no longer specific to either Rust or Fedora ]

Posted Nov 1, 2022 9:12 UTC (Tue) by farnz (subscriber, #17727) [Link] (8 responses)

This is, however, working around a failure of the distros. If they're providing a carefully curated, ready-to-use version of the software, then they should not be shipping versions that cause issues, and they should be reverting updates that do cause issues or fixing forwards rapidly, so that end users (the people you're giving advice to) don't have to upgrade and downgrade individual dependencies themselves. End users (including developers like me) only want to think in terms of the final complete application, not its full dependency graph.

Distros, in turn, make this part of their job harder on themselves by requiring a single version of each dependency distro-wide (and yes, this has other benefits); that means that if (say) Scribus needs features from libpango-1.44, while Inkscape has problems with libpango-1.44 but not libpango-1.43, they're stuck until the pango dependency is fixed by the distro or by upstream. Static linking inherently avoids this, since they could then ship just Scribus with libpango-1.44, while keeping Inkscape locked to libpango-1.43 until the bug is resolved. In this setup, you wouldn't need to advise people on which version of libpango to have installed, since they'd have the "right" version for the application they were running.

As with so much else in life, this is a set of tradeoffs. The distros have found a set of tradeoffs that acts as a local minimum for C and C++ applications (which is great!), works well enough for interpreted languages, and doesn't work well for Java, C# and Rust. They got away with it not working well for C# and Java because those languages run in their own VM anyway, and the VM is a C application, but they're now having to look for the next local minimum if they are to ship Rust applications.

My hope is that the result of hunting for a local minimum for Rust applications will result in the distros finding a better overall state - not just for Rust, but also for C and C++ applications.

shared libraries [ no longer specific to either Rust or Fedora ]

Posted Nov 1, 2022 17:36 UTC (Tue) by sfeam (subscriber, #2841) [Link] (7 responses)

In the case of pango, my understanding is that the breakage was deliberate, in the sense that someone made a choice between adding support for new font types on very high resolution displays was more important and keeping in place a framework that was designed for older font types and displays with a mere 95dpi (see e.g. https://github.com/harfbuzz/harfbuzz/issues/2394#issuecom...). On the one hand I have a bit of sympathy for pango having to choose between a new framework that is supportable going forward and an old framework whose support has languished. On the other hand, that means people downstream who were perfectly happy with desktop text rendering on their existing systems saw it as breakage. It's a whole lot easier to advise "replace this one library and your desktop will work again" than to say "you'll have to rebuild your whole desktop infrastructure to fix this, or stick with an old version of the whole system, or buy new monitors or change the fonts in your existing apps and documents, etc". The distros were caught in the middle, and may well not have been aware of the forced choice between backward and forward compatibility.

This particular problem is not one of "program X requires version a.1, while program Y requires version a.2"; it's more "this user needs version a.1 for both X and Y to work, while that system over there needs version a.2 for both X and Y to work".

I'm not really following your comment about distros requiring a single distro-wide version dependency. Maybe some do? but I haven't encountered that. My experience has been that if you upgrade in place over a period of years, you gradually accumulate multiple versions of support libraries because local and 3rd party apps don't necessary rebuild against the latest library versions in sync with the distro release schedule. That's minorly annoying, but so what? OK, you have to be careful not be overly enthusiastic about deleting old library versions, but you have them backed up, right? And for that matter the older version is probably still downloadable from the distro if you know what you are looking for.

shared libraries [ no longer specific to either Rust or Fedora ]

Posted Nov 1, 2022 23:43 UTC (Tue) by ssokolow (guest, #94568) [Link]

I'm not really following your comment about distros requiring a single distro-wide version dependency. Maybe some do? but I haven't encountered that. My experience has been that if you upgrade in place over a period of years, you gradually accumulate multiple versions of support libraries because local and 3rd party apps don't necessary rebuild against the latest library versions in sync with the distro release schedule. That's minorly annoying, but so what? OK, you have to be careful not be overly enthusiastic about deleting old library versions, but you have them backed up, right? And for that matter the older version is probably still downloadable from the distro if you know what you are looking for.

I think they're talking about how distro maintainers do things like maintaining their own patchsets to un-vendor libraries, even if that puts things into a configuration upstream does not approve of and refuses to support.

shared libraries [ no longer specific to either Rust or Fedora ]

Posted Nov 2, 2022 9:28 UTC (Wed) by farnz (subscriber, #17727) [Link] (4 responses)

Ah. In the case you're describing, you're building an unsupported configuration - it's a very short term workaround, since sooner or later, the packages users depend upon will require the newer pango's ABI and not work with the older pango's ABI. You're trading bugs - you've got users to choose an unsupported configuration (since the distro maintainers will tell you to update to latest releases first) that works for now, in preference to a supported configuration where bugs can be fixed.

Unless the distro explicitly supports this action, you're creating more trouble down the road - the user will at some point have to choose between a pango that works but doesn't display nicely on their display, or not running a current version of their application. In a statically linked world, they'd have to choose older application version that displays nicely, or newer one that doesn't - and that's a tradeoff the users understand - complete with "I won't upgrade from Debian 13 to Debian 14 because it breaks my Scribus" attitudes. What you've got users to build is a system where things are unreliable (because sometimes they will run things that accidentally or deliberately depend on the ABI of newer pangos), and where they cannot see their way clear to a fix (because ABIs aren't something the typical user understands - they just have two bits of information, "program X crashes" and "I can't upgrade pango").

The long term solution is to work with upstream - either deliberately fork pango, and have two alternatives you can install as a deliberate act, one with the old engine, one with the new, or get the new engine to the point where it's as good as the old on low-DPI displays - because anything else gives users the illusion that they're running a supported system, while actually having a system that'll break at a moment's notice.

And in terms of distros requiring a single version - the default in all distros I've looked at is to say that you can't install both pango-1.43 and pango-1.44 at the same time. You have to choose one or the other; eventually, if there's a pango-1.46 that adds new ABI that an application depends upon, users using your "fix" have to upgrade and accept the problem. Further, most distros explicitly don't support you running a mix of older and newer packages; if you want distro support for anything, you need to run the distro update mechanism and run the latest versions of all packages. In the case of users who've pinned an old version of pango, they're out of luck if they want distro support, because the distro attitude will be "well, you're running outdated code. You need to upgrade pango to fix it".

shared libraries [ no longer specific to either Rust or Fedora ]

Posted Nov 2, 2022 12:36 UTC (Wed) by Wol (subscriber, #4433) [Link]

> And in terms of distros requiring a single version - the default in all distros I've looked at is to say that you can't install both pango-1.43 and pango-1.44 at the same time. You have to choose one or the other; eventually, if there's a pango-1.46 that adds new ABI that an application depends upon, users using your "fix" have to upgrade and accept the problem.

Dunno whether it's the "default" or not (and I haven't had the need to use it myself), but gentoo's slot mechanism allegedly makes running multiple versions easy. Maybe other distros should have something similar?

Cheers,
Wol

shared libraries [ no longer specific to either Rust or Fedora ]

Posted Nov 2, 2022 12:54 UTC (Wed) by anselm (subscriber, #2796) [Link]

And in terms of distros requiring a single version - the default in all distros I've looked at is to say that you can't install both pango-1.43 and pango-1.44 at the same time.

Most distros, however, will let you install pango-1.x and pango-2.x at the same time. The general idea behind this is that pango-1.44 should support everything that pango-1.43 supported, plus perhaps some extra stuff, so that it doesn't matter if you swap pango-1.43 out for pango-1.44 because applications that have so far worked with pango-1.43 will just ignore the new extra stuff, and upgrading pango for applications that do require the new extra stuff in pango-1.44 shouldn't be a problem as far as other pango-using applications are concerned.

If stuff from pango-1.x actually goes away then the new pango should be 2.0, and applications that depend on pango-1.x should just be able to keep using the older version because the two versions can be installed side-by-side. How well the authors of individual software packages adhere to this philosophy is, of course, anyone's guess (and of course there's the edge case of an application relying on a bug in pango-1.43 and breaking when the bug is fixed in pango-1.44, which arguably is not the pango package's fault).

shared libraries [ no longer specific to either Rust or Fedora ]

Posted Nov 2, 2022 16:40 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (1 responses)

> And in terms of distros requiring a single version - the default in all distros I've looked at is to say that you can't install both pango-1.43 and pango-1.44 at the same time

You *could* if pango-1.43 and pango-1.44 where both packaged and maintained (and for a lot of components this is technically possible, just rename the pango-1.43 to oldpango-1.43 to allow two version streams in parallel).

However *no* *one* wants to expand the effort to package multiple versions of the same thing for you. The amount of work snowballs quickly.

shared libraries [ no longer specific to either Rust or Fedora ]

Posted Nov 2, 2022 17:15 UTC (Wed) by farnz (subscriber, #17727) [Link]

Indeed - and the ability to pin an older version than the distro supports is not a real fix for that very reason. Without someone stepping up to maintain a fork of pango-1.43 suited for use on systems that don't gain from the changes in pango-1.44, you're trading off a known bug (the rendering issues in pango-1.44 on "normal" screens) for future problems (unknown bugs in pango-1.43 fixed in a later pango-1.x release including security-relevant bugs, ABI changes in later pango-1.x that increase the blast radius of trying to pin 1.43 etc).

Ultimately, while this is nice for debugging whether or not it's a pango change that's breaking things, it's a dangerous route for fixing things - it results in an unsupportable system because you can't rely on users having the versions of libraries you expect them to have (because they're "randomly" pinning versions that happen to not have bugs that annoy them, and then complaining because there are bugs they don't like).

shared libraries [ no longer specific to either Rust or Fedora ]

Posted Nov 3, 2022 9:16 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

The full move to Harfbuzz is required to properly support modern opentype (TTF and OTF) features, be it latin legatures, non latin scripts, emojis, color, etc. Harfbuzz has two decades of enhancements, fixes and rewriting over the old freetype code it was originally forked from.

High resolution (aka banal 4K screens) is not directly involved, except inasmuch the very old pre-opentype fonts that render worse with the new system, mostly because they were designed around the old system bugs, are useless on such screens (way too small). And also, they look like crap compared to banal vector fonts rendered on such screens: there is a point at which no amount of pixel hand-tuning can compete with more pixels to render fine details. It’s no longer distorted sharp vs blurry fidelity, it’s sharp fidelity vs blocky pixelated that relies on old bugs.