On Wed, 2023-03-29 at 08:25 -0700, Fritz Hudnut wrote:
Leap 16.0 Putting high level requirements for Alpha. I think I could have something usable by end of this week. https://en.opensuse.org/Portal:16.0 So far everything shows that base system will have traditional 12 months + overlap support.
[QUOTE] Migration path from the previous releases
Users will be officially able to upgrade to Leap 16 only from the openSUSE Leap 15.5 transactional update server and from Leap Micro 5.X. There are experimental tools that can be used to migrate a non-transactional-update system, but we highly recommend doing a clean installation instead. The migrated system would have to be btrfs based.
[/QUOTE]
This is good news . . . will this migration path from 15.5 be available sometime soon? Or, the repos will have to be edited to "16" to make it to Alpha stage materials??
F Let's first finish 15.5, shal we? :)
At the moment, Leap 16.0 is merely a draft project. It will be based on SUSE's ALP project (based on current knwoledge, SUSE ALP has had various prototypes) Essentially, it's heading in the direction of MicroOS Desktop i.e. immutable OS (transactional system). 'Upgrading' from Leap 15.x to Leap 16.x is technically only viable for Leap 15.x that were installed as transactional servers, simply due to the fact that there the partition layout, btrfs config, and the read- only capability are a given. Regular 15.x installs (normal desktop installs) are not installed on a read-only system and thus are 'too different' to migrate On MicroOS/ALP, the root file system is on a Read-Only partition, upgrades are installed onto a btrfs snapshot and on reboot the new snapshot being used as active one. Workloads are generally coming in the form of 'containers' (podman for system services, flatpak for actual applications). The clear line where 'base OS' ends and 'application layer' starts is still to be defined. MicroOS Desktop is the perfect example for the direction it is heading. Distrobox is supposed to be used for anything you are 'playing' with, i.e compiling stuff, installing random stuff; that's isolated from the base OS, and actually allows you as much flexibility as you wish to have, even having different containers running different OSes (think: one container with Tumbleweed for the newest flash, one container where you build up your app based on Leap 16 RPM's to be more stable, one container where you can have Python 3.12... all without risking the actual underlying Base OS). The separation allows for faster moving parts where they are useful - one thing which was a real pain with Leap 15.5 is the still very old python interpreter for example. /usr/bin/python3 can't easily be changed to not be python 3.6 anymore, as that would break the backwards compatibility promise: scripts that worked on 15.4 are supposed to be compatible with 15.5; python 3.10 is not 100% backwards compatible. Changing is thus 'bad'. But with 16.0 we can separate those things out - i.e. you build a container with Python 3.6 for you workloads where you need to run scripts compatible with this version and another container where we can offer newer python interpreters (the interpreter is just one example - always look from the leaf application down to what is best for this, and then combine things as they make sense). Those changes are very positive in my opinion. It allows for Leap 16.x to have a rather 'small-ish' set of base packages, that need to be tightly coupled. The rest comes in form of containers, which can have entirely different release cycles for example. Help design the new system - don't be scared of the change. Think about what you actualy want to do with the system and design workloads that help you achieve those things. Let's make openSUSE Leap 16.x the OS that 'gets out of your way and allows you to use your applications without you having to take care of the OS' Cheers, Dominique