Am Wed, 06 Jul 2022 11:48:07 +0200
schrieb Dan Čermák
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 * 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? * 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?
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?
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)?
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? Are we expecting all our users to manually copy their ~/.config/* into the new ~/.var/app/* place? Are there maybe even internal differences (YAML vs INI-Style)?
8) Will the whole delivery chain stay secure (signing of flatpaks, SSL, DNSSec, ...)?
Yes. This is one of the strict requirements to ALP.
Thanks! Lars