6

I need to upgrade the Ubuntu Version on my servers, but I do not want to upgrade the installed packages. Is this possible?

Halsi
  • 87
  • 1
  • 5
  • 18
    This sounds like a [x-y problem](https://xyproblem.info/). *Why* do you want to upgrade Ubuntu version, but stay with old packages? – vidarlo Feb 03 '22 at 20:44
  • 1
    Indeed @vidarlo, venturing a guess, it sounds like "I need to upgrade for compliance reasons but am trying to avoid dealing with incompatibility or breakage at this time." – briantist Feb 05 '22 at 16:01

4 Answers4

20

Your question indicates a misunderstanding of what the release version of Ubuntu actually means.

‘21.04’ is not some random number, it’s a guarantee that:

  • Packages available at the time of release of that version of Ubuntu are still available to users of that version of Ubuntu.
  • Any newly released versions of those packages in that version of Ubuntu will retain binary compatibility with the versions of packages provided in the original release of that version of Ubuntu.

In other words, the set of packages you have available and installed defines what version of Ubuntu you are using. That’s the whole point of the version number, it concisely defines the state of the platform so that users and developers can quickly verify compatibility.

This is no different with Windows, or macOS, or FreeBSD, or pretty much any Linux distribution that doesn’t use a rolling release model. It’s also no different from versions for any other type of software.

Austin Hemmelgarn
  • 2,295
  • 9
  • 15
  • That's not entirely true. You could have some (non-essential, at least for the OS itself) packages from, let's say, third-party repositories, that work perfectly on both of the distro's versions, which you don't want to upgrade. Nonetheless `do-release-upgrade` forces you to. I find it a little bit annoying that you cannot force skipping it. – Lethargos Oct 17 '22 at 11:36
  • That's not quite true. In Windows, you can have many software installed and typically none of that is removed during system upgrades. – s.ouchene Dec 17 '22 at 22:13
  • If that's the case, then logic would indicate that one of two things would be correct: Either the newer version gets a date stamp and doesn't include package dependencies prior to the date stamp. Or the alternative, each new release of Ubuntu has an ever-larger quantity of dependency data. It would be nice to know which way it works. – Gray Feb 02 '23 at 09:24
  • @s.ouchene My reference to Windows is not about applications, it’s about the OS itself. For example, Windows 11 build 22621 defines an _exact_ set of versions for all the components that are inherently part of the OS. You can’t randomly have a different version of some component like the print spooler and expect the system to work correctly. – Austin Hemmelgarn Feb 02 '23 at 12:41
  • 1
    @Gray Kind of the first case, but not quite. During the development cycle, the development repos regularly have old versions of packages removed. As an example, Ubuntu 22.10 has two versions of the tzdata package available, 2022e and 2022g. 2022e has (probably) already been removed from the development repositories for Ubuntu 23.04, so 23.04 won’t have that specific version of tzdata when it gets released. – Austin Hemmelgarn Feb 02 '23 at 12:51
9

No, this is not possible. If you don't update the packages, you don't have the new version.

Gerald Schneider
  • 23,274
  • 8
  • 57
  • 89
  • Is it possible to exclude some packages from the upgrade? – Halsi Feb 03 '22 at 10:38
  • 2
    No, not really. If you need specific versions for some cases you should take a look at containerization. – Gerald Schneider Feb 03 '22 at 10:52
  • it really depends on the package too - some you may be able to pin if they were added by you – ti7 Feb 03 '22 at 21:50
  • 5
    You can 'pin' a package to keep it from being upgraded. But if a newer version of the pinned package is required for other packages, then it will prevent their upgrade also. Depending on the system criticality of the resulting package holds, this can lead to a cascading effect resulting in a failure to get to a 'Version' upgrade. Not a good situation to be in. – dave58 Feb 04 '22 at 01:41
  • @Halsi Do you want to upgrade or don't you? If you exclude some packages from the upgrade, then you didn't upgrade, you partially upgraded. – David Schwartz Feb 04 '22 at 08:20
  • 3
    @Halsi whilst it might be possible to avoid upgrading non-system packages (packages installed from third party sources such as PPAs, for example), binary compatibility on Linux can be complex and hard to reason about. Part of the benefit of using a specific version of a distro is that this reasoning has been done for you, for all the packages in the repository. If you want to use packages built for a different version of the distro, you'll need to understand these complexities and deal with their consequences yourself. – James_pic Feb 04 '22 at 11:39
4

There's no "Ubuntu version" without the packages. Actually, there is no Ubuntu without the packages.

Ubuntu is just a vast collection of packages, and an Ubuntu version contains specific version of packages. To actually update Ubuntu, you'll need to update them.

You can always pin down some package version, but expect things to behave weird.

If you want some brand new package on an old Ubuntu version, you can consider using Backports.

John Kugelman
  • 103
  • 12
blue112
  • 143
  • 1
  • 7
2

A Linux distribution is a collection of packages. A particular version of a Linux distribution is a collection of particular versions of packages.

The notion of "upgrading the distribution without upgrading the packages" is non-sensical: the distribution is the packages, the packages are the distribution. The version of the distribution is the versions of all the packages that are part of the distribution.

The term "Linux distribution" comes from a time when the World Wide Web had just been invented, Internet access was rare, broadband Internet access barely existed outside of universities, government institutions and very few very large companies, there were no project hosting hubs like SourceForge, BitBucket, or GitHub, there were no software aggregation sites like Freshmeat.net, Freecode, freshcode.club, or Fresh FOSS.

If you wanted to install a Linux system, you had to get each individual component directly from each individual developer via individual ways (sometimes FTP, sometimes rcp, sometimes Usenet, sometimes even on physical floppy discs per snail-mail), compile all of them yourself, figure out which versions of package A were compatible with which versions of package B, and so on.

What Linux distributions did, was to collect all of those packages from their individual developers, make sure they work well together, and put all of them on a single set of floppy discs, on a single CD-ROM, or on a single FTP site, so that they could easily be "distributed" together as one single thing from one single place instead of having to hunt for them all over the place.

That's what the term "Linux distribution" means in essence: a collection of packages designed to work well together, available from a single place. Over time, Linux distributions added more and more features to their offerings: package managers that make it easy to install and uninstall packages, installers that make it easy to install the distribution on a new system, sometimes, the distributors developed their own software when they felt there was a particular lack of options. They started developing consistent look-and-feel across applications, etc.

But at their core, they are still a collection of packages.

Jörg W Mittag
  • 2,138
  • 1
  • 18
  • 17