"David C. Rankin"
On 7/7/22 16:31, Robert Schweikert wrote:
But the isolation comes with a potentially heavy price, to come back to what was stated a couple of times in this thread "we can ship the same flatpak on TW, Leap SLE...". True but that implies that your flatpak is really fat.
It can get really, really, really fat quickly. Apps using a different version of plasma or frameworks5 can literally need close to 1G of dependencies just to run.
Certainly, but I imagine that we will have policies preventing exactly this. E.g. if you want to build a KDE flatpak, you have to use the KDE-stable or KDE-latest runtime. This would prevent such a bloat.
There is far more downside and risk to commit to a flatpack approach than to maintain the status quo with a tight distribution, proper .spec dependencies and a SLE release based on a defined set of gcc, python, etc....
Hard to imagine a company with $2B in annuals and $1/2B quarterly just wants to throw flatpacks at it? https://ir.suse.com/websites/suse/English/6400/quarterly-reports.html
Somewhere someone with little regard for openSUSE has made the decision to cut costs. Gleaning from the last few weeks on this list that means killing off openSUSE releases in lieu of SLE/ALP and Tumbleweed alone. The cost saving vision that one flatpack for Tumbleweed and ALP/SLE will cut costs. That seems horribly naive.
Take your tumbleweed developers and look at what breaks every time there is a change in Python, or gcc or glibc or toolkit like Qt/Gtk/Frameworks5/Plasma or supporting library like libpng or libssl and on and on (take your pick). TW's flatpack/dependencies would remain somewhat unchanged in size and dependency content. However the impact SLE/ALP will be layers of differing versions of dependencies depending on whether the TW changes introduced versions not backwards compatible with current SLE/ALP (that happens a lot keeping a rolling release going). Even subtle upstream changes in obscure packages can introduce huge backward incompatibilities. (take icu 71 for example, and that's just one library introducing incompatibility in 1/4 of the releases packages)
One aspect of ALP (that has not been mentioned here as this was originally just about the desktop) is to re-imagine the software lifecycles and provide means to have multiple streams of software components co-existing at the same time but be decoupled of the support cycles of the main distribution. This would allow you to build packages not necessarily on the "latest and greatest"^TM from Tumbleweed, but also from more "stable" runtimes.
None of it results in cost savings but the guaranteed result is a huge growth in size and risk of requiring multiple versions of whole swaths of packages and libraries for SLE/ALP through flatpack. And if flatpack "sharing" isn't perfect, then that could happen on a per-package basis.
This pinned on the hope that currently non-existant tooling will minimize the bloat and multiple versioning problems. I think that is worth a proof-of-concept.
A wise path would be to proceed with 15.5 and for proof of concept do the same flatpack for ALP and TW. Mark the day the ALP/TW flatpack approach begins. Then after 6 months of development see where you are on the one flatpack approach. I suspect that ALP will suffer greatly due to the scenario described above.
Leap 15.5 will happen, there are no plans (at least none that I am aware of) to cancel it because of ALP. The plan is afaik more or less what you're saying: ship Leap 15.5 and work on ALP in parallel.
If it works, then kudos, there is more promise than I see in the approach. If it doesn't and we find ourselves having to push out some flatpack cobbled together ALP needing 2 DVDs worth of installer to meet an artificial release deadline -- the downside to flatpacks will have been borne out. But due to wise foresight, doing it in parallel with 15.5 done in a traditional way, you will still have one quality offering ready to go.
Somewhere in the $500,000,000.00 in 1st quarter revenue, there has to be enough money to do this right and not just "hope" for the best. A one-flatpack between ALP and TW with at least 3 kernel versions and python versions and 7 gcc versions in between -- what could possibly go wrong?
I hope it all works out and that ALP is stellar and one-flatpack for ALP/TW is the answer, but I've lived too long and witnessed far too many slow-motion train wrecks built on hope and unproven concepts.
How many more https://download.opensuse.org/distribution/leap/15.4/repo/oss/x86_64/FreeCAD... and https://bugzilla.suse.com/show_bug.cgi?id=1200583 are we going to have?
Well, ALP should hopefully prevent exactly these issues from cropping
up. Given that flatpaks have very little dependencies on the base
system, a flatpak running on Tumbleweed should also run on Leap or ALP
or everywhere else.
Cheers,
Dan
--
Dan Čermák