On 3/30/23 05:33, Dominique Leuenberger wrote:
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'
On the designing a new system, we proved that you could take ALP's sources and build a distro with all the core components not in containers and on a read write filesystem without transactional updates. That should be upgradable from Leap 15.5 as long as tumbleweed still is. We worked with a much more limited set of packages but proved it would be possible for the community to maintain and I plan to work on something like this again after the 15.5 release when more of ALP is more mature But I can only commit to a pretty core set of packages so to get even close to feature parity with Leap it will require a bunch of community involvement to get close to feature parity with Leap. At the same time for things the community doesn't provide as RPM's the ALP containers will work fine. But as I said in the other email i'll have a talk on it at the conference. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B