Eric Schirra
Am Montag, 11. Juli 2022, 09:55:45 CEST schrieb Dan Čermák:
possibly needed python modules. That's a lot of work. So much more work and therefore much more time. And with
every other program I have to do that again.
Calibre will be a challenge, if possible at all. At Flathub they don't build it from source, but repackage the build that is provided by the developer (although there is an effort to make it build from source). See the bugreport:
https://github.com/flathub/com.calibre_ebook.calibre/issues/17
Still, with flatpak we would be able to provide a version for Leap, even if it is difficult. And the work done at flathub can provide a starting point, maybe.
Calibre serves me here only as an example. And I mean increasingly to read that this and that package may not work. So more and more packages actually can not be built as you want in ALP!
And if I understand you correctly, you want to take a package that was built somewhere else and distribute it in Leap. So that what is prevented until now always and everywhere in SUSE and in the build server. Download of npm or python module or the installation of binary packages from upstream itself are prevented or forbidden. And now this should be allowed for flatpacks? I can not understand.
Somewhere else is in this case still the Open Build Service using the same packaging guidelines and the same review processes. The only real difference is that you can distribute your flatpak for Tumbleweed, ALP and Leap (and Fedora, Debian, Ubuntu, etc.).
You will *not* be allowed to just dump random prebuilt stuff from the internet or run npm install in the build service. That is against the very idea of packaging applications. Please do not mistake flathub flatpaks with our flatpaks: we do intend to use flatpaks as a distribution mechanism but not adopt flathub's lenient packaging policies.
But further above it was said "but package the build provided by the developer". Which now? Build from upstream or build from OBS? Could it be that the people suggesting ALP don't agree themselves yet?
And if only OBS. Then I don't understand the whole thing at all and see absolutely no added value. The goal of ALP and container should be, if I understand it right, that more packages run under different "suse distributions". But who does the work then? Create Rpm, create flatpack. The whole thing at the update again. Where is the added value? Where is that less work?
The flatpak should be build from rpms in OBS. However, you could build one flatpak and distribute it for ALP, Tumbleweed and everything else out there, without having to care about dependencies on anything but your chosen baseline (which could be Tumbleweed or something else). This is where the time saver comes in: you don't have to try to keep your package building with ancient python, ruby or whatever else versions, because you can pick your baseline. And since the builds are still being done via rpms, our existing packaging and review guidelines apply, so we *do* provide additional value: 1. the packages are build according to the same quality standards 2. the packages are available for more distributions with less overall work
I stay with it. The whole topic is an idea of the business administration people at SUSE. As in other areas of the economy, unfortunately.
The last version of calibre that could have been built for Leap would be 4.23.0. This also runs on my Leap. And that this can not be built, are the ancient packages in Leap (SLES) and here especially the dead python 3.6. The main problem from my point of view is the extreme dependency of Leap to SLES. Something should be done here. I use Leap because I actually want a stable system, so I don't need the latest packages everywhere. Does not bring anything for me. But there are just a few packages that I really want to have up to date. And I think it's the same for some people. But how to bring this under one hat, unfortunately, I have no solution. Only flatpack and container is not the solution for me.
I would like to understand why a flatpak or a container is not a solution for you?
Because we want to introduce them to solve exactly your pain point: ancient packages in the base OS that cannot be updated due to stability guarantees. I feel your pain with an ancient python, I have had exactly the same troubles with Ruby for vagrant and boost for RStudio. If I could build them into containers or flatpaks, then I'd be able to distribute vagrant and Rstudio for Leap users with little additional effort. Currently I'd have to jump through far too many hoops to make this doable.
Again, I would really like to know why this wouldn't work for you, because we'd like to build an OS that caters for more people and not less. I'm not saying that you can't solve the problem of ancient packages with containers. You could. It's just that I don't like it at all. For me, it tries to solve a problem that requires a certain amount of work to solve with another layer that requires even more work. In addition, there is another layer that can contain errors. The complexity increases. And when openSUSE wasn't so tied to SLES, I understand the reason, the problem didn't exist to such an extent. But as I said, I don't have a real solution either. Unfortunately.
We can certainly create a new spin on Leap that will provide more up to
date versions of python, ruby, etc. But the elephant in the room is that
someone has to maintain all of this. The close tie to SLE "solves" this
to a certain extent, obviously at a cost.
Cheers,
Dan
--
Dan Čermák