Lars Vogdt <lars(a)linux-schulserver.de> writes:
> Am Wed, 06 Jul 2022 11:48:07 +0200
> schrieb Dan Čermák <dcermak(a)suse.com>:
>> > 1) What are the advantages of flatpak/container vs RPM?
>>
>> Flatpaks support sandboxing when configured properly giving you
>> greater security benefits in comparison to traditional rpms.
>>
>> The main benefit however is that we would be able to build certain
>> desktop applications (e.g. Firefox, Thunderbird, LibreOffice, etc.)
>> only on top of Tumbleweed, put them into a flatpak and distribute
>> them to Tumbleweed, Leap and ALP users. This is something that is
>> impossible to achieve with RPMs unless you bundle *everything* into a
>> single RPM and even then it will probably not work. So this will save
>> our packagers a tremendous amount of work.
>
> While I understand that this makes the live of a packager easier (at
> least in the future, when we got rid of all the old-school
> distributions), I think that we loose a big benefit of the current
> way to do it.
>
> 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.
> * We need to find a way to track, if a Flatpak contains a vulnerable
> library and push out security updates for all involved Flatpak
> (containers). I think/hope, that OBS can help us here?
The plan is to build *everything* inside OBS. So updates will be
distributed the same way as they are currently, only the artifact at the
end will change.
> * For any library update, we increase the needed space on all mirror
> servers and also require much more bandwidth from all endusers - as
> they need to download a whole copy of all Flatpaks with all their
> in-tree libraries.
> -> Is there already a project like "deltarpm", which might help to
> reduce the amount of 'need to be transferred' Flatpak content for
> any update?
Again, this would go into the runtime, which would be shared by all
flatpaks. I must admit that I am not familiar with the flatpak
distribution method enough, thus I cannot answer whether there is
something like deltarpm.
>> > 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.
>
>> > 4) Will there still be some kind of repo (incl. package
>> > informations like version-release, changelog, etc.) for flatpaks?
>> >
>> > 5) Will Yast-Software manage all these different kind of formats
>> > (container, flatpak, rpm) transparently for the enduser?
>>
>> I don't know what the plans of the Yast team wrt flatpaks are, but
>> GNOME Software center supports flatpaks and rpms seamlessly.
>
> So this means more work for the Yast team.
> Are they aware of this?
> Did they maybe even already agreed to implement this in the near future
> (before the first official release of ALP)?
I have CC'd the Yast ML to get their take on this.
>> > 6) Can configuration still be expected at the usual places
>> > ($HOME/.config/ : /etc : /usr/etc/)?
>>
>> That depends on the flatpak, but generally flatpaks put their
>> configuration into ~/.var/app/
>
> 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 we expecting all our users to manually copy their ~/.config/* into
> the new ~/.var/app/* place?
As you'd have to reinstall the system anyway, you'd have to move your
configs into different places.
> Are there maybe even internal differences (YAML vs INI-Style)?
Any internal differences would be caused by the packaged application
itself. Flatpaks do not mandate any type of configuration format, as at the
end of the day they are just archives that get unpacked on your file
system (just like rpms…).
Cheers,
Dan
--
Dan Čermák <dcermak(a)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
