Fedora project leader Matthew Miller weighs in (TechRepublic) [LWN.net]

Fedora project leader Matthew Miller weighs in (TechRepublic)

Posted May 1, 2022 12:00 UTC (Sun) by atnot (guest, #124910)
In reply to: Fedora project leader Matthew Miller weighs in (TechRepublic) by amacater
Parent article: Fedora project leader Matthew Miller weighs in (TechRepublic)

> The newer languages went off and re-invented several wheels instead of actually working out how to do dependency tracking, linking and so on

I'd say it's the exact opposite. Language developers saw that distributions weren't solving their problems, namely:

- cross-platform builds and dependency management
- allowing people to easily install and develop against multiple versions of a package
- allowing regular delivery of up-to-date libraries to users, on their own schedule
- effective integration with build tools
- sensible, low-friction workflows that don't require learning seven arcane file formats, shell scripts, semi-maintained perl tools, ftp, email and waiting weeks for people to ack your changes in multiple long queues

The only package manager that even comes close to solving any of these is the regrettably hard to use Nix. C can barely get away with this on unix for historical reasons. Although arguably, C build tools have become language specific package managers in their own right, just very inconvenient ones. Meson is moving in that direction. But if any new language that hasn't yet established a big ecosystem chose to start out with this model today it would fail instantly.

to post comments

Fedora project leader Matthew Miller weighs in (TechRepublic)

Posted May 4, 2022 7:48 UTC (Wed) by hvd (guest, #128680) [Link] (2 responses)

I think the GP had it right. In Rust, the situation we have now is that buggy packages are abandoned upstream and pull requests fixing the bugs are left for years to rot, those packages cannot be fixed in a single place by distributions since each user comes with its own version, and Rust actively prevents the copies that come with their users from being fixed by checksumming the vendored sources. Language developers are recreating the problems that distributions had solved ages ago because they're doing it all over again from scratch without learning from the past.

Fedora project leader Matthew Miller weighs in (TechRepublic)

Posted May 4, 2022 8:19 UTC (Wed) by mpr22 (subscriber, #60784) [Link] (1 responses)

In C, we have buggy libraries abandoned upstream with patch submissions left for years to rot... and my observational experience is that distros tend towards "drop it", not "attempt to gain momentum as the new upstream".

Fedora project leader Matthew Miller weighs in (TechRepublic)

Posted May 4, 2022 9:49 UTC (Wed) by farnz (subscriber, #17727) [Link]

And worse, some distros build up forks of everything where they've "fixed" it, and neither admit that there's now a "distro" fork and upstream, nor succeed in pushing those fixes upstream (because upstream is gone, or at least on hiatus).

This causes problems in at least two cases:

Upstream becomes active again, and starts doing their own fixes. These can conflict with the distro fork, and now the distro has the problem of either not updating (and having to handle users who wonder why the distro ships an N year old version of something in its "latest" distro version) or porting everything that depends on the distro fork to upstream.
Users find documentation that doesn't account for the fork (that's based on upstream, or another distro's fork), and apply it to their installation. They then get frustrated because it doesn't work the way they expected it to - because the distro fork has changed behaviour enough that the documentation they have found does not apply.

In the Rust case, the distro has to admit that it's forked the package - it has to become a "new" upstream for at least the packages in the distro, forking all of them, too - and my experience suggests that this is a good thing in the long run, because it enforces a degree of self-reflection from the distro maintainer who can't let "just one more little fix" build up into a full fork accidentally, without also having the maintainer being aware that they're forking the library with all that that implies.