This is not a flatpak request. I would just like to know Flathub’s (and others) position on legacy app support. In this post I am defending the idea that Flatpak should be used to resurrect quality discontinued apps or keep stuff on life support until it is ported to GTK3, python3 ect… as opposed to letting things just die. It is far less of a security risk because of the sand boxing and network disabling. High quality discontinued apps such as (Jokosher, CelestiaQT, mhwavedit, Gnash SWF viewer, Ekiga, and much more exist. Linux and GPL in general has a small pool of software in general for non-programming task and every time we lose a title it is a monumental shame because it hurts the minority audience of front end workers on Linux.
Windows has extremely long term back/forward compatibility. Mac has about six years or so of back/forward compatibility, but Linux has next to no binary support and I hope flatpak can fix this. I am not saying we should indefinitely hoard flatpaks and waste disk space, but instead of deleting old stuff it can be put on https://www.archive.org and valuable apps that are “endangered/recently discontinued” should be given a few years time on Flathub to encourage people to fork them. Everyone knows Linux is extremely favorable to programmers and sysadmins, but struggles with quality front end production and work software. If we want Linux to be more helpful for people who do presentation and graphical work/hobbies (like myself) you would consider using Flatpak to temporarily rescue recently discontinued apps.
Thank you for taking the time to read this. Please consider and ponder upon this idea.
The only two I needed in this list were mhwavedit and hotshots. I was just pointing out others that got discontinued. I guess someone might need them but not me. I am learning how to make flatpaks so I can save legacy apps, however I do not expect FlatHub to host them and I am fine with that.
I’ve pushed a couple of unmaintained apps to Flathub - Tomboy and GLabels - they don’t impact on the infrastructure/storage cost of Flathub a great deal, and they work for the jobs they were intended for, so I think this is a fine use of the technology. If library deps/versions are sensitive to later changes, a fixed runtime environment is ideal.
I agree with @ramcq in that Flathub allows for this. For example I published PDFedit flatpak which is a very useful legacy app but uses old and unmaintained libraries, for that reason I put the following disclaimer in the Flathub description:
---------- DISCLAIMER ----------
This is legacy software which uses old unmaintained libraries (Qt3, Xpdf 3.02) for which there are no security backports, therefore you should NOT open any untrusted pdf files with this software. Because of this, we have restricted the application to only have access to the standard “Downloads” and “Documents” folders, so you may need to copy/move your pdf file there so you can open it with PDFedit.
I think it’s a good idea that legacy apps included similar disclaimers.
In that regard, a nice Flathub feature would be to allow tagging an app as legacy and so Flathub included that disclaimer automatically (or even force to not use --filesystem=host).
I thought the way Flatpak works makes hosting legacy stuff significantly easier then building against a systems libraries. If a legacy app needs a old version of several popular libraries doesn’t flatpak make the process much more straight forward? Like you can make a runtime with the old stuff and instruct the legacy app to look their for its libraries without intefering with modern apps version of that library.
Exactly, you can keep using an old runtime if that works better for your app. It will be marked as EOL as it gets no security updates, but that’s a trade-off the app developer needs to make. I’m pretty comfortable not having any security updates for a note taking or a label printing app.
