On Wednesday 06 July 2022 16:01:31 Benjamin Zeller wrote:
Am 06.07.22 um 13:56 schrieb Dan Čermák:
Adam Majer
writes: On 7/6/22 09:15, Dan Čermák wrote:
Would you mind to elaborate why? I would like to stress out that you will not be "forced" to download Firefox from flathub. You will get the same Firefox as you get today from OBS, it will just be a flatpak and not an rpm so that it can be reused across all released distributions (actually any Linux distribution supporting flatpak).
The point Michael seems to be making is that currently he can go to command line (or package manager in GNOME) and do `zypper in MozillaFirefox` and it's installed. And then when the system is updated with `zypper patch`, everything is updated.
From a user standpoint, it's very important that having different technology behind it, like flatpak, does NOT break the user experience when it comes to keeping the system or the applications updated or installing the application in the first place.
So it doesn't matter if it's flatpak or RPM or whatever, it's really important that we don't have a Windows-like experience when it comes to updates where everything is on its own. Our basic job is not to make RPMs - we are *integrators* and a distribution is an *integration*.
This is a very good point!
Michael, Benjamin, what's your take on this?
I agree with that, this is why I suggested to have a unified tool to update the systems that can handle all sorts of different backends. rpm, flatpack, transactional etc etc. Back then ppl disagreed with the idea because the backends might be too different to be unified behind one tool ( I'm still convinced we could find a abstraction that works). So I did not follow up on the idea, but i still have a document describing it more in confluence if anyone is interested.
It was written 2 years ago and would need some updating to match our current situation , the general idea would still be valid though. Btw, in theory libzypp also could handle different backends but it probably would need to match a package based concept.
Yes, zypp is a bit package-centric. But if you can imagine to automatically build a 'flatpack:MozillaFirefox-VERSION_RELEASE.rpm's from some source, which upon their installation/update/removal install/update/remove the corresponding MozillaFirefox flatpack and you can also imagine to maintain your flatpacks via your repo of `flatpack:` rpms, then you can also think about integrating flatpack: into libzypp (of course without actually building such rpms). Then 'flatpack' would become a kind of Solvable, like package,pattern,patch and product. We did something like this long (long) time ago, as a POC for RubyGems, however incl. actually building such rpms. But the rapidyl increasing amount of 'real' ruby .rpms stopped it. Nowadays we would not need physical .rpms, though the rpm rules (naming,versioning,dependencies) must be applicable. I don't say it's little effort, but the route would be quite straight IFF flatpacks fir into the schema.
A admin moving between different SUSE installations should not have to use completely different set of tooling to keep the system up to date, but even more important the admin should not need to remember all the different sources where software was installed from. "Did we use flatpak or rpm on this machine, or both?"
Definitely. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres (he/him/his), Engineering & Innovation, ma@suse.com +------------------------------------------------------------------+ SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany, (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman +------------------------------------------------------------------+