Lars Vogdt <lars@linux-schulserver.de> writes:

...

...

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?

As far as I know flatpak utilizes seccomp to achieve the isolation and not cgroups. Iirc cgroups are more for limiting resource usage and not security sandboxing, but this is really far outside of my knowledge.

...

...

...

...

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.

In devel projects yes, but the actual package sources of the released code streams are separated and have often significantly diverged from the state in the devel project.

But this brings me to two other questions:

10) Is there something like _multibuild support planned for Flatpak?

I cannot answer that, as I do not know what the Build Service team has planned here.

11) Will there be a tool to convert spec files into Flatpak files?

No, and that should really not be required. The idea is that you combine multiple rpms into a flatpak and not that you convert a rpm into a flatpak.

...

...

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?

I don't think there are and imho the technical complexity of that would make such a migration next to impossible to pull of cleanly. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman