Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Comments on Why/how can distro support lifetimes exceed the lifetime of their dependencies (such as Python)?

Parent

Why/how can distro support lifetimes exceed the lifetime of their dependencies (such as Python)?

+3
−0

Motivating example: my Mint 20.3 distribution offers long-term support until April 2025, which matches the "standard support" offered for the upstream Ubuntu (20.04 "Jammy Jellyfish"). However, the system-provided Python version is 3.8, which reaches the end of security support this October, half a year earlier.

Similarly, the next LTS Ubuntu release (and corresponding Mint release) are based on Python 3.10, which will similarly EOL half a year before the end of support for the Linux distros. Both Python and Ubuntu/Mint offer a total of 5 years of support (Ubuntu Pro notwithstanding), and Python now has a 1-year release cadence while Ubuntu and Mint do major-version LTS releases every 2 years - so they are advancing in lock-step.

Should I expect my system Python to be automatically updated (or to be prompted for an update) at some point? Or else, why would the maintainers deliberately offer an additional 6 months of support for an OS that depends on a no-longer-supported version of Python?

More generally, how does it make sense to offer this kind of support schedule, outlasting system components that are no longer maintained by their respective authors?

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

Post
+3
−0

When an upstream project stops supporting a version (e.g., Python stops supporting 3.8), the maintainers of the distribution do the job of supporting those components, applying security patches as necessary.

You can expect that their knowledge of the project isn't as comprehensive as that of the programmers of the upstream project. Also, one packager tends to be responsible for hundreds of packages, which is not ideal. As a consequence, the support is often not-so-good, and only security vulnerabilities are fixed, not just every bug. (There are exceptions, and in some cases, the support from your distribution may be better than the original support from the upstream programmers.)

It can make sense because some upstream projects may not support stable branches at all, so from day 0, distributions need to take care of back-porting bug fixes. You could say that a version in those projects is EOL the day after the release.

In some other cases, upstream may support stable branches, but for a time that the distribution considers too short. For example, Debian releases every 2 years, and releases are stable for 2 years, then oldstable and oldoldstable, with a support of almost a decade in total. Most upstreams won't commit to maintaining branches for a decade, so someone from Debian must do the work.

Why do it? Because if you have a system that works, it costs money to update it to use a newer version, and it's also risky. Of course, it's also risky to use an outdated version that might have bugs that were (sometimes accidentally) fixed in newer versions and nobody noticed that the old versions should be patched. And it also costs money to support old versions. But it's a balance where doing it might be worth it.

For a personal use case, since the cost of upgrading the OS in your personal computer is low (and the eventual time cost of an upgrade from oldoldstable to stable could be significant, as too much changed at once), I think it makes more sense to run stable or even unstable OS versions on personal computers. As long as you trust the distributors to not break those versions too often that they're unusable. I've been using Debian unstable for many years and rarely had any problems with it, and only minor ones for a few days.

If you run a company with 1000s of servers that you don't want to break ever, you may consider it good to pay some distribution developers to fix security vulnerabilities in EOL packages that you use, so that you don't need to upgrade those systems' OSes, which could cost a lot more than that.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

Comprehensive, thank you (2 comments)
Comprehensive, thank you
Karl Knechtel‭ wrote 3 months ago

Thanks for the comprehensive overview. It makes perfect sense to me.

I went in to this thinking that I wouldn't want to upgrade the entire OS more than every 4 or 5 years anyway, but it feels like I pay a heavy price in terms of software versions being much further out of date than I expected, and often not even having access to more recent versions in the package manager. I've been thinking about trying to find something that uses the rolling release model but is still comfortably far back from the bleeding edge by default.

alx‭ wrote 2 months ago · edited 2 months ago

Debian Sid is that thing for me. In some cases I must be cautious and not do some upgrade, but other than that, it's usually fine. I usually do sudo apt-get update && sudo apt-get upgrade -V, which is fine (and that would usually be enough in Debian Stable). After that succeeds, in Sid you also need to apt-get dist-upgrade -V, which you need to check that it doesn't try to remove things or do other weird stuff; as long as it only uninstalls lib* packages, it looks good and I proceed.