Re: ALP WG Meeting minutes - July 5th 2022
Jan Engelhardt <jengelh@inai.de> writes:
On Wednesday 2022-07-06 11:48, Dan Čermák wrote:
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.
But that is not inherent to the flatpaks themselves. As you say, flatpaks are but a different method of _distributing_ software. And so the critique becomes: stop distributing software twice.
That's what will happen. Currently we distribute software for every code stream and with flatpaks we hope to reduce the burden on our maintainers and allow them to distribute it only once.
To make flatpaks (or, at this point: sandboxes) more widely accepted, generate them on the fly from an existing system, i.e. from {an rpmdb and loose files} rather than from a set of .rpm files.
Sure, that would be nice to have. But creating such a system is a lot of work which is really hard to justify if there is already a perfectly functioning and widely adopted system in place. 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
On 7/6/22 20:20, Dan Čermák wrote:
Jan Engelhardt <jengelh@inai.de> writes:
On Wednesday 2022-07-06 11:48, Dan Čermák wrote:
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.
But that is not inherent to the flatpaks themselves. As you say, flatpaks are but a different method of _distributing_ software. And so the critique becomes: stop distributing software twice.
That's what will happen. Currently we distribute software for every code stream and with flatpaks we hope to reduce the burden on our maintainers and allow them to distribute it only once.
This is simply not true, let me take an extreme example for fun. If you look at the package setserial you will see that we ship the exact same binary for all of SLE-15 and its service packs, you'll also see the sources are identical for tumblewed (the package hasn't changed in 8 years). Also looking at a more relevant recent example of something that would be shipped as a flatpak under your model being the Terminology Terminal Emulator, for Leap 15.4 I just copied the tumbleweed sources across and everything was fine, I would have done the same for the last time it was updated in 15.2 this equates to about 10 minutes of effort each time. But under this new model your suggesting that as well as building an RPM for tumbleweed I also need to build a flatpak? How much effort do you estimate this will take? because your trying to make it sound like as a packager this will be less effort for me when it certainly sounds like more. This is just 2 simple examples in other packages I maintain such as dbus and cmake there is always careful consideration into do we actually need a new version for this stream or can we continue sharing the old ones. My final question is where do we want to draw the line here? I also maintain the conky system monitor i'm not sure how that would work as a flatpak and if it makes sense, similarly the fish shell could be seen by some as a system thing but for others they may just want to install it for there own users so should things like interactive shells also come from flatpak's where do you suggest the line should be here? -- 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
Hi On Wed, 06 Jul 2022 12:50:18 +0200 Dan Čermák wrote:
1) What are the advantages of flatpak/container vs RPM?
That's what will happen. Currently we distribute software for every code stream and with flatpaks we hope to reduce the burden on our maintainers and allow them to distribute it only once.
For me this kind of means we retire from the current way to deliver well tested (but maybe older) software to Leap users and deliver the latest and greatest stuff to Tumbleweed users. 13) How can someone decide to use an older, but known to be stable version of a package (say: Libreoffice 7.2.7 instead of Libreoffice 7.3.4) in ALP? with kind regards, Lars
Lars Vogdt <lars@linux-schulserver.de> writes:
Hi
On Wed, 06 Jul 2022 12:50:18 +0200 Dan Čermák wrote:
1) What are the advantages of flatpak/container vs RPM?
That's what will happen. Currently we distribute software for every code stream and with flatpaks we hope to reduce the burden on our maintainers and allow them to distribute it only once.
For me this kind of means we retire from the current way to deliver well tested (but maybe older) software to Leap users and deliver the latest and greatest stuff to Tumbleweed users.
13) How can someone decide to use an older, but known to be stable version of a package (say: Libreoffice 7.2.7 instead of Libreoffice 7.3.4) in ALP?
We haven't made any decisions in this regard (like with a lot of other stuff), but with flatpaks we could deliver a org.opensuse.libreoffice-stable, org.opensuse.libreoffice-beta, org.opensuse.libreoffice-nightly, etc. co running "streams". With containers we could go the already established tag route, i.e. registry.opensuse.org/opensuse/libreoffice:stable registry.opensuse.org/opensuse/libreoffice:beta registry.opensuse.org/opensuse/libreoffice:nightly 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
participants (3)
-
Dan Čermák -
Lars Vogdt -
Simon Lees