Am Samstag, 9. Juli 2022, 22:16:30 CEST schrieb Cor Blom:
Op 09-07-2022 om 16:01 schreef Eric Schirra:
Am Samstag, 9. Juli 2022, 14:41:42 CEST schrieb Stefan Brüns:
On Freitag, 8. Juli 2022 23:19:22 CEST Carlos E. R. wrote:
Does this mean that the flatpack of calibre would contain inside the proper version of python? Would this not mean that we would need powerful computers with huge hard disks, to have this pentaplication of libraries, and a corresponding large CPU to cope with all this?
It would be the end of using Linux on old computers. If this is so, I have to find another distro.
Each Python 3.x would probably be a flatpak runtime. On top of that you could have an "extra" (or whatever) runtime layered on top, which includes a set of very common dependencies/python modules.
You can think of flatpak runtimes as somewhat coarse-granular set of packages. There likely is *some* waste due to duplication or not strictly required depencies, but in most cases this is neglegible.
The calibre flatpak than only has to bring additional modules which are not included in the runtimes below, and are very often only used by this single application.
But that's a bit naive. Calibre needs about 40 python modules. If we assume that it would work with the "flatpack collection packages", then surely no one will first search these "collection packages" for 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. The whole hubs, no matter if python, npm or whatever had recently increased security problems and I assume that this will increase. And then SUSE guarantees me a clean system and takes over the liability if I use SLES or SLED? I can not believe it. Whereby... With the answers you get as in SLES....... 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. Regards Eric