Simon Lees
On 7/11/22 19:05, Dan Čermák wrote:
"David C. Rankin"
writes: 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.
Yes but also as far as i've heard there are no plans to do a Leap 15.6 or to have a SLE 16 / Leap 16 but rather have a Leap somehow based off the ALP stack. Maybe to continue the tradition of random numbers for major Leap releases we should call it Leap 87 [1].
I think another thing worth noting here is that if all of ALP's containers / flatpaks or whatever they end up being are based off rpm's built in obs it might be possible with some effort to put all or most (some might conflict) of those RPM's into one Repo and not require ALP users to use Flatpaks or containers but this would probably take slightly more effort from the community but unlike coming up with a complete new distro like we had before 42.1 (think 13.2, 13.1 and earier) this is probably more intergration work rather then packaging work and might be easier to manage. At the end of the day how the openSUSE community takes the Piece of ALP that its given and uses them will be up to the openSUSE community.
I guess you could _aggregate all packages from which flatpaks are build
into one giant repository and hope that the buildservice does not run
out of disk space due to that.
--
Dan Čermák