> > They basically provide a fully self-contained package containing a tool > (like Evolution) and ALL of its dependencies, as a single bundle. > These dependencies are not installed separately on your system: they > are not visible to any other program "outside" the flatpak. And the > Evolution in the flatpak doesn't use any of your system libraries, it > only uses the libraries in the flatpak. So there's no way they can > introduce dependency hell.
I know this is getting way of topic, but this is primarily why I shy away from Flatpak. You download a blob of "stuff" and you have no real idea what is in that - it could be some ancient bug-ridden library that the dev has decided to use because that's what was on their system when writing it 20 years ago and they can't be bothered to update it. It's not a theoretical risk either: there's an application I use at my day job and they specifically said that the only way of running it now is to use containers because it will only work on an ancient version of Ubuntu and so they packaged all the old libraries into a container so they don't have to support modern systems. I would hope that something like Evolution is not so crass, but it always strikes me as a way for devs and maintainers to not do it properly! (And yes, I understand you run the same risk with statically compiled applications - I also don't like them.) > > And if it doesn't work, well, it's a self-contained separate bundle so > you can either just ignore it, or remove it: it doesn't interfere with > anything else on the system. That's the point. And the fact that it doesn't interact with anything makes it less integrated into your system - unless you go through a load of arcane Flatpak command line arguments to make it talk to your environment. Yes, I know it's not that difficult, probably. But it's also not always as straightforward as you are making out. > > These days even the recent RedHat Enterprise distros can do an upgrade > without reformatting the disk (finally!). Hmm, I know Fedora does quite well at it, but I don't think I would trust the RHEL major version upgrade - the whole point is that my big iron has the same enterprise version for the whole of it's physical life, it gets retired rather than upgraded! P. > _______________________________________________ > evolution-list mailing list > evolution-list@gnome.org > To change your list options or unsubscribe, visit ... > https://mail.gnome.org/mailman/listinfo/evolution-list _______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list