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)?
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?
Post
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| Karl Knechtel | (no comment) | Apr 1, 2024 at 05:20 |
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.
0 comment threads