"Critical" projects and volunteer maintainers [LWN.net]

"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 13:50 UTC (Thu) by cyperpunks (subscriber, #39406)
In reply to: "Critical" projects and volunteer maintainers by martin.langhoff
Parent article: "Critical" projects and volunteer maintainers

"to go back to larger libraries maintained collaboratively by a community of maintainers", I would argue such community exists: it's goes under the name of Red Hat & Fedora, Debian & Ubuntu, openSUSE & SLES etc.

No end user should ever need to use pypi and similar repositories.

In fact if could be argued such repositories does more damage than good to software development, it's not a sustainable way forward.

to post comments

"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 15:07 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

I would argue such community exists: it's goes under the name of Red Hat & Fedora, Debian & Ubuntu, openSUSE & SLES etc.

Which does nothing for people who run Windows or MacOS. Even on Linux, it doesn't help very much for bleeding edge libraries under rapid development, which may be too new to have gotten attention from the distribution and may be way out of date if they have. Personally, I think the approach to developing that depends on those unstable, bleeding edge libraries is deeply flawed. Obviously there are plenty of developers who disagree, and the languages have decided to side with those developers.

"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 15:20 UTC (Thu) by NightMonkey (subscriber, #23051) [Link] (6 responses)

+1 The point of Linux distributions I thought was to provide exactly this. A "curated", "opinionated", but generalized compendium of applications and shared libraries, maintained and updated in a consistent, more predictable fashion than just downloading random software. The first time I saw application developers 'reinventing' distributions with CPAN, then RubyGems, then VirtualEnvs and such, I thought to myself how tough it will be to administrate *that* mess... and it is. (Don't get me wrong, I use those userspace distribution models now, too, but it is still doesn't feel like a good solution to the question of managing software and software dependencies. My hat is off to those who maintain those language-centric package repositories.)

No longer like "herding cats", but "herding cats that herd cats"! :D

"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 17:20 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

The problem with distros is that they bring a lot of other unwanted baggage as well. Like not being able to use packages from one distro in another one. Or the extremely slow speed of development.

"Critical" projects and volunteer maintainers

Posted Aug 2, 2022 12:10 UTC (Tue) by immibis (guest, #105511) [Link] (1 responses)

You might be surprised how often packages WILL work on the wrong distribution. Occasionally I unpack debs on Gentoo, and they work.

"Critical" projects and volunteer maintainers

Posted Aug 14, 2022 12:11 UTC (Sun) by flussence (guest, #85566) [Link]

One of Gentoo's worst-documented features is that it can *output* binary packages (default is tarballs, but it also does RPM). It's an afterthought, not an OBS alternative, but it's sometimes a lifesaver to have.

"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 18:10 UTC (Thu) by atnot (guest, #124910) [Link]

In addition to the things others have mentioned, the suggestion that we should only have system package managers and those should "curate" the libraries has a big bootstrapping problem.

Distros are limited in the amount of new packages they can review. The queue for new packages in most distros is hundreds to thousands of packages long. As such, they usually require that a package be of a certain age and popularity or depended upon by something that is.

So yes, you can say, "why would I use pypi/cpan/etc. when all of the best libraries are in my distro already". But that's ignoring that the only reason that rich ecosystem of libraries exists the first place is because enough people were willing to install it in other ways that it became worth packaging. And that popularity was only possible because installing it those ways was easy for users[1].

[1] It's also worth considering that the only reason your distro can afford to maintain those tens of thousands of python/perl/etc packages in the first place is because those packages exist on an index, in a format standardized enough that you can just use automated tools to repackage it with little extra work, instead of as disorganized tarballs on Some Guy's personal website.

"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 23:51 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

I would argue that CPAN, at least, is not an attempt to reinvent distributions, since it was created around the same time as the first Linux distributions. It has been in service since 1995, and distributions have changed a lot about the way they work since then. Not to mention that any system designed to distribute libraries in 1995 that restricted itself to Linux just wasn't fit for purpose. I would argue it isn't fit for purpose today, since many developers today aren't working on Linux. Leaving out all developers who work on non-Linux OSes wasn't sensible in 1995, and it still isn't today.

"Critical" projects and volunteer maintainers

Posted Jul 15, 2022 15:15 UTC (Fri) by NightMonkey (subscriber, #23051) [Link]

I agree with your point about CPAN. I shouldn't have included it - its reason for existence is older and broader than many of the other language-packagers.