|
|
Log in / Subscribe / Register

Conill: The long-term consequences of maintainers’ actions

Conill: The long-term consequences of maintainers’ actions

Posted Sep 19, 2021 13:59 UTC (Sun) by Vipketsh (guest, #134480)
In reply to: Conill: The long-term consequences of maintainers’ actions by ilammy
Parent article: Conill: The long-term consequences of maintainers’ actions

> Resources are scarce

Why am I the only one who thinks this goes two ways ? An app or such not wanting to upgrade dependencies because it is work is reasonable as things stand today. But seemingly a dependency re-inventing itself causing tons and tons of cumulative resource burn for all downstreams is also reasonable, considering how no one complains about it.

Unless libraries keep some semblance of a stable public facing ABI things are going to be as bleak as the grand-parent post makes out. What's funny is that that exact situation has happened in the C world before: the fiasco that resulted when lots of projects are/were embedding zlib and a vulnerability was found therein. It took years to clean that mess up and instead of learning from that people are just setting up to the same situation all over again.

> upstream does not really want to support the entire combinatorial explosion of their package and all possible dependency versions

IMO, that's nothing but myth. The only versions (of dependencies and the app) that need to be supported are the ones that people actually use (with few exceptions what distributions ship) and there are not a lot of those. I also don't think upstream needs to be as forceful about versions as many seem to be. The linux kernel folks have the right mentality: promise to fix regressions, but at the same they freely make changes without checking them with some "combinatorial explosion of versions". If it breaks your code, it is up to *you* to report it and work with the upsteram devs to get it fixed. Don't report it and/or don't cooperate then it doesn't get fixed. Projects taking this attitude would go a long way for downstreams and I don't think it would cause *that* much more work for upstream.

> Developers use the latest version, it’s natural for them

Unfortunately, it goes the other way too and then causes just as much pain for the user. There are many projects that moved or are still moving from Python 2 to 3 at the last minute. Or maybe even past that.


The LWN site is currently under high scraper load, so comment display has been suppressed for anonymous users. If you are a human, you may read the comments by clicking the button below:

Note: you can avoid this step in the future by logging into your LWN account.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds