Robert Schweikert
On 7/7/22 16:45, David C. Rankin wrote:
On 7/5/22 10:46, Dan Čermák wrote:
the fear is not necessarily flatpaks (probably)
Wrong,
That is exactly the fear. I wouldn't touch a flatpak or containers with a ten foot pole. I don't need 3G or dependencies for every "hello world" app that I may want to install. I don't need multiple versions of the same package installed as a flatpack dependency for different apps. I don't need to waste resources with a native apache setup and a containerized implementation of a groupware package that runs on its own containerized apache. No thanks.
New approaches are fine if they eliminate problems and bloat. New approaches are not fine if they create new problems and increase bloat. Flatpack is an ill fit for a mature desktop distribution and more geared toward teenagers installing "apps" on smartphones.
Funny, but there is a certain amount of truth to it.
The angle that is missing from this point of view, IMHO, is the necessary integration work.
Meaning as long as the necessary integration work is done, i.e. what we practice today, than flatpak, containers,....other formats of isolation are indeed mostly just overhead.
However, if the integration work for apps A, B, C,.... is not done and they all get their own copy of the dependencies in the versions that they need then flatpak or other delivery mechanisms that provide isolation are necessary.
Such isolation, from a developer point of view, has the advantage that if a team responsible for a dependency moves that dependency forward to a version that is incompatible with the app I maintain, I can stay behind and keep my own copy of the dependency version that the app needs. Meaning the other team cannot force me to do integration work on their time scale, I can do the integration work when it fits my time schedule or when upstream moves the dependency forward and then I worry about the packaging only. Also works the other way around, if the upstream of my app moves to a newer dependency version I can pick it up in my isolated environment and I do not have to wait for the team maintaining the dependency to catch up. This second case is generally less of a problem for Factory but certainly for slower moving distros. This is an advantage for isolation.
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. If I build a flatpak for a python app and the flatpak is based on what I built in TW then that flatpak by necessity will have to include the Python 3.10 interpreter if I want to run that flatpak on SLE. And things will probably have to creep further down the stack since the Python interpreter needs a C runtime environment which comes from the gcc compiler that is in TW and that's not in SLE, and as such that also has to be thrown into the flatpak. Meaning it's not so easy as it is being made out to be, IMHO. This however is a technical problem and can be solved with tooling.
Sure, but this size increase will get smaller if you install more than one flatpak, provided of course that they share parts of the runtime (which would be desirable).
What is not solvable with tooling is that the isolation and me staying behind has the disadvantage that I, as the app maintainer, am now taking responsibility for a version of the dependency for which I may no longer get help from the team that maintains the dependency. And that may mean that if a bug shows up I am on my own and the user maybe SOL as I may not have the expertise to fix/address the problem in the dependency that I am shipping in my flatpak, container... Meaning I probably have to do the integration work that I procrastinated with right then and there anyway.
You are not wrong, but shipping a different dependency than upstream bears other risks as well. While your dependencies will get maintained by someone else in the distribution, you run the risks of subtle regressions. Additional, with sufficiently complex applications, there's really no way of checking that the different dependency version did not break something in a subtle way. Additionally, upstreams often tend to be hesitant at best with helping out in these cases and understandably so: they ship the application with dependencies pinned to certain versions to reduce their QA effort. So to be frankly honest here: both approaches have their downsides and upsides. We still will ship rpm content, but it will probably be limited to the parts of the system where dependencies don't have to be pinned. And the parts which are getting increasingly complex and where even unbundling all dependencies is a non-trivial effort, will be shipped as flatpaks or maybe not at all… I will probably get a lot of hate for this, but we have to always ask ourselves, whether packaging something really provides any value to our users. And if all that we do is recompilation with all bundled dependencies, then that added value is getting really small (albeit not zero).
There are tradeoffs that have to be weight and the speed of the distribution and the development model have a big influence as to whether or not such isolation is worth it. There are certainly good examples for either case where isolation is worth it and where isolation is not worth it.
As such having the necessary tools to go either way is certainly a worth while effort and then the decision about delivery format, rpm vs. flatpak, vs. container vs... is up the the developer/maintainer of the bits higher up the stack. For some developers doing the integration work whenever a dependency moves might be easy, see Wolfgang's message, and for others it may be painful and they'd rather maintain their own copies of dependencies.
And then of course we have to consider how this mix of things looks from the user point of view. If the user has to know that application A is delivered as a flatpak and as such requires a different command for updating than application B that is delivered as a plain rpm then we are going to create a mess that no user is going to want to deal with.
Definitely, the user experience should not suffer and we can take Ubuntu
as an example here, who afaik integrated snaps into apt directly
(thereby also making a lot of people very mad when `apt install firefox`
gave them a snap…).
Cheers,
Dan
--
Dan Čermák