Ubuntu 26.04 LTS released in April, bringing a new long-term foundation for cloud systems, on-premises devices, and personal computers. With every LTS release, the crafts are updated with a new Ubuntu base and new features.
If you publish snaps, charms, rocks, or images, now would be a good opportunity to review the changes and update.
Ubuntu 26.04 LTS bases
With the 26.04 release comes new LTS bases, which contain the common and essential packages from the main Ubuntu repository. Craft artifacts depend on these packages at runtime.
All crafts support one of the recently-released 26.04 bases. For Snapcraft, it’s the core26 snap. For the rest, it’s the ubuntu@26.04 container image.
If your snap, charm, or rock uses a 24.04 base, and you need new features and packages from 26.04, you can migrate:
If you were testing a 26.04 base while it was in development, your project file (snapcraft.yaml, charmcraft.yaml, rockcraft.yaml, and so on) no longer needs the development values for the build-base and grade keys. You can update those keys and repack, and your artifact will be stable and ready for use in production.
Forward slashes in part names
Every software part inside an artifact needs a unique name that communicates its purpose. For example, a part that builds traefik from source would probably be named traefik.
Internally, crafts also make use of hidden, non-user parts, which begin with a namespace prefix that is delimited by a forward slash (/). The automatically-generated core part in Snapcraft, for instance, is named snapcraft/core.
To avoid accidental collisions between user parts and these internal parts, we adjusted the naming rules. Starting with artifacts based on 26.04, part names can’t contain forward slashes. If you have prior part names that contain them, you must replace them with another character, such as hyphens (-).
Snapcraft and Python
The Core team marked the core26 snap as stable on 11 June, and a significant change was the removal of the Python runtime.
We have two reasons for doing this. The first is that the core snaps must be small in size, and we saw an opportunity to shrink it further. The second is that providing a single version didn’t meet how developers actually approach Python in their snaps. Python offers itself in many concurrent and minutely incompatible versions, and the simplest way to prevent regression and limit their compatibility commitment is to pick one or two, ideally one. Over the years we’ve found that snap authors pick one version, and stage it and and the corresponding C libraries, ignoring the defaults in the core snap.
If you’ve already been shipping a Python runtime in your snap, you don’t need to take extra action when migrating to core26.
If, like me, you were using the default Python runtime, you must add Python as a separate part when migrating to core26. We have plans to make repackaging Python easier in a later release.