...

Please correct me, if my assumptions are wrong: * A Flatpak will include all needed libraries, which will blow up the needed (installation and mirror) space

No, flatpaks support runtimes which would contain the required libraries and these are shared between different flatpaks. E.g. on flathub you already have a GNOME runtime and a KDE runtime. We could create our own openSUSE Tumbleweed runtime and base our flatpaks on that.

This sounds to me like: "Flatpak is just another packaging format. But instead to rely on packagers to provide Apparmor/SeLinux profiles, Flatpaks are using cgroups from the beginning, which makes them more secure." - Is that description close enough to the truth?

...

...

...

2) Will ALP still allow one 'zypper up' call to update all software (container, flatpak, rpm) on a system?

3) Will OBS auto-convert current rpms to flatpaks?

Theoretically that could be done, but I think that's at the moment out of scope.

For 2, does this mean we loose the current benefit of updating a whole system with just one single tool?

So for 3, this currently means that packagers have more work, because they need to provide the needed Flatpak build configuration as well?

Not really. Currently a packager has to provide a spec file for every code stream and maintain those independently and make them build. With flatpaks in the mix, you'd have to maintain a single code stream and a flatpak build description.

IMHO this answer is wrong. Most packages in OBS are not using spec files for every code stream, but include macros in one single spec file to build for multiple code streams. But this brings me to two other questions: 10) Is there something like _multibuild support planned for Flatpak? 11) Will there be a tool to convert spec files into Flatpak files?

...

How is a migration from RPM to Flatpak expected in this case?

Afaik there are no plans to support a migration from SLE to ALP.

Are there plans to support a migration from openSUSE to ALP? Regards, Lars