appimagetool: Prevent AppImages from being created if AppDir ingredients are too new #74
Comments
|
This is a horrible idea that should be rejected immediately. |
|
How about printing at least a very clear message including a link to the documentation, and requiring explicit confirmation ("press Y to continue anyway")? In think that this issue needs to be fixed at the root, at the moment in which the developer is using our low-level tools, rather than after then fact when the damage is already done and a subpar AppImage is already out there in the wild. |
probonopd
changed the title
|
Every AppImage author will just suppress and/or ignore this, since it completely ignores the circumstances. The tool is unaware of the situation, it may be totally okay to, e.g., just support the last 2-3 years of distributions. There is no need for paternalizing users of appimagetool. This issue is twofold: a) unrealistic promises made by you/AppImageKit/AppImage website/AppImage docs What you suggest is unlikely to have the desired effect (see linuxdeployqt's lengthy CLI option to ignore that one check, which is widely used in repositories (https://github.com/search?q=unsupported-allow-new-glibc&type=commits, way over 8000(!) commits), and off-putting for new users (see your own issue tracker, apparently you found yourself compelled to add this option after complaints from many, many users). Worse even, it adds unnecessary complexity to a tool and repository which are complex enough already. Interactivity as you suggest it is another bad idea UX wise. I just spent over a week trying to make both AppImageKit and AppImageUpdate work significantly better by replacing all the gpg subprocess stuff with GPGME, since the interactive gpg(2) CLI has caused tons of issues in automated headless processes for me (and likely many others). I strongly recommend you to never ever consider interactive questions ever again. Making them behave correctly in non-interactive terminals adds complexity and costs time. Instead, you could just fail and suggest a CLI option (as you have done it in linuxdeployqt, however please note I'm not suggesting to do this in appimagetool). The real solution to this is to leave the decision entirely to the AppImage authors and correct misleading statements from "our" side, e.g., "works everywhere" should at least point to a footnote explaining that this is possible and should be the default case but up to the application authors. Requirements like "this has to work on this system at least" can at most be suggestions ("best practices").# I know I said this before: please stop editing your comments adding new content after you posted them. When writing elaborate replies, it's annoying to have to take additional statements into account. It's perfectly fine to correct, e.g., grammar. I know I do this as well occasionally, but it's bad and we should feel bad about it. |
|
I suggested interactivity so that it will not be used in CI scripts ("see linuxdeployqt's lengthy CLI option to ignore that one check").
The result would be that some AppImage authors just don't care; out of laziness ("it works on my system") they would produce AppImages that wouldn't work for others in the way the AppImage format is intended. As a result, the reputation of the AppImage format would be damaged ("it just doesn't work"). Also, I would have to deal with even more "broken" AppImages (as in: don't pass the tests according to my standards on https://appimage.github.io/). |
|
I'm not willing to seriously continue this discussion. It's a bad idea, and your reply shows that your intentions are bad (blocking in CI to coerce users into silly and unrealistic standards which they may not be able (or typically not willing) to fulfill). This is extremely off-putting and damages the reputation of AppImage as a technology much more, since potential users may not even be able to use it. To pick up your edit (which, again, is annoying to reply to), this is your problem, not the world's. These "standards" are arbitrarily picked and never had the backing of said community, even core developers like myself have spent a lot of time and effort in the past explaining why these are not coming from AppImage as a project but you personally and are flawed. |
|
So far, we've been guilty of "Engineering based on hope". |
|
No, the opposite is true, we must not. This entire idea makes so many false assumptions, I don't even know where to start. |
|
How can we entirely prevent situations like this? |
|
I think a warning is OK but an error is too much. The warning could become an error if you opt-in to a "pedantic" mode.
It's actually much fewer commits https://github.com/search?q=%22unsupported-allow-new-glibc%22&type=commits. GitHub splits the search term on hyphens unless you put the search term in quotation marks. |
|
Fair enough @shoogle.
Again, these checks are completely arbitrary, do not have the backing of anyone but you, and are completely out of scope for this project.
This just adds unnecessary complexity. It's either on the deployment tool to do these checks (linuxdeployqt being the only one that performs checks like these), or post-deployment linking (there's appimagelint which does this pretty well, and works with any AppImage). |
Ah, I didn't know about appimagelint. It works great, thanks! A standalone linter is indeed the best solution, though it might be a good idea to bundle it with If you run squashfs-root/* # All of MuseScore's files
squashfs-root/appimageupdatetool-x86_64.AppDir/* # All of appimageupdate's filesSo we literally just put the contents of appimageupdatetools's AppImage inside MuseScore's AppImage (see here and here). You could use a technique like this to bundle |
|
I'm aware of that technique, see e.g., https://github.com/linuxdeploy/linuxdeploy-plugin-appimage/blob/8fce62d23abf436aee47b98c0ee50422a4ea7cef/ci/build-appimage.sh#L56-L58. We've done that in some tools before already. I wouldn't even go so far to bundling it. And appimagelint doesn't, like, fail if a specific compat level isn't reached (though we might want to add that some day as a separate CLI flag). It is and will always be upon the authors to decide which compatibility level they need and can support. I think we have to break down the issue to the two audiences AppImage has: users and developers (read: AppImage creators). Users may have trouble running AppImages (binary incompatibility is just one issue, there may be other runtime incompatibilities even if the AppImage appears to start up correctly). Developers may be unable to fulfill such criteria (reasons include economic limitations, lack of time (especially for hobbyists)). The following is a little unorganized, but contains lots of reasons against the current practice in AppImageHub. Most of them are not novel, they've been explained a lot in the past. Maybe it helps @probonopd understand the refusal of this weird rule in AppImageHub among the AppImage team. I've been working with people in companies to create AppImages of professionally developed software. In many, many cases they are strictly limited which dependencies, programming languages or platforms they may support. For instance, a couple years ago, there was a discussion whether or not to support C++17 within the AppImage community. With some effort, it was possible to produce C++17 binaries which were ABI compatible to CentOS 7 on CentOS 7 with a special compiler toolchain called devtoolset (still is, by the way, we use it in AppImageBuild which is used to build AppImageKit, libappimage, etc.). However, some projects just decided that they do not want to spend time to make that work. It is their free choice to, e.g., build on Ubuntu 20.04, which even provides all the necessary dependencies (i.e., they do not have to be built manually). IIRC, this is how Xournal++ started. Nowadays they build on 18.04 and produce compatible binaries (according to appimagelint). However, to get started, 20.04 was a completely legit target in 2019, even though 16.04 still existed. The point is, it is totally okay to get started with a very recent base system. This allows packagers to get started and become familiar with AppImages. It can always be optimized by investing a significant amount of time, sure, but even if it isn't, that's fine. Some tools might be such niche tools they might just have to run on some super recent base system (e.g., a little helper that fixes a tiny bug for a small amount of users on Ubuntu 22.04 when using some specific hardware). Running compatibility checks is always a good idea, especially on catalogs like AppImageHub. What I strictly reject is to add such rules as "this must run at least on random system". As said, there are so many valid use cases to violate an arbitrarily chosen rule like "must run on oldest still-supported system". This is why we (i.e., everyone but @probonopd) call this a "best practice", not a rule. It's very off-putting to newbies and contributors being limited and paternalized like this for no good reason in such an arbitrary way. Another argument against such arbitrary gatekeeping: just being able to run in theory on all systems since 2018 because it is built on Ubuntu 18.04 doesn't mean the AppImage may run. Binary compatibility is just one aspect (it might be the most important one, though). The application may require other dependencies from the system, e.g., styles, icons, themes or other things. Compatibility needs to be tested anyway. Companies who want to do this properly need to employ QA engineers, i.e., this costs money. Software with a certain amount of complexity (e.g., software that interacts with filesystems) might be used in combination with many base systems with different filesystems, so the amount of possible combinations easily grows to very high numbers (e.g., 10 distros and 5 different filesystems result in 50 possible combinations (calculating the cartesian product of both sets)). Most open-source tools can't ever do what's necessary, even though we strongly recommend them to test the outcome on as many systems as possible. Just limiting oneself to a set of certain systems is completely reasonable in that scenario. The software may still run on other systems, but it's not officially supported then. Every developer knows that principle, and most users do, too. The root cause of all the issues and problems mentioned by @probonopd is the lack of proper communication. AppImage catalogs typically lack compatibility matrices, e.g., "this AppImage will run on Ubuntu >= 20.04, Debian >= bullseye, Fedora >= 35, ...", which would really help users (AppImageLauncher could probably integrate such a feature as well to become more user friendly). Gatekeeping just means that for all the "off limits" AppImages that don't make it into the catalog, such information will never become publicly available, and also, those users have zero motivation to ever improve the situation. They might even drop AppImage support because it's more effort to work around such weird limitations than to add a little "by the way, this won't run if your system is older than X" hint on their download page. Our other audience, AppImage creators, need to understand much better the reasons for this recommended best practice (e.g., the majority of all users runs these kinds of systems, giving some examples for typical user groups who can't choose their base system freely (e.g., university labs, workplaces, server systems). They must be explained the consequences of violating that rule. They need to be taught how they can improve their AppImages' compatibility (e.g., "use CentOS 7 with devtoolset" or "use Ubuntu 18.04 with the ubuntu-toolchain-r PPA and linuxdeploy-plugin-checkrt"), and that it's completely okay to get started with a recent base system because they can always improve later. To summarize: claiming that binary support (or the ability to make a screenshot automatically) on some arbitrarily chosen distribution does not imply that the software will run correctly there. This is something that cannot be auto checked. It's unrealistic and therefore wrong to make such a claim in catalogs like AppImageHub. Therefore, such a check should not be implemented, this kind of gatekeeping does not make sense. Instead, what really helps users is (auto) generating compatibility matrices, collecting user feedback (e.g, like wine does), educating users that these matrices are just a guideline (i.e., making no unrealistic promises but raising awareness for the limitations of such measures). Developers on the other hand need to be informed about best practices like the one that has wrongly been turned into a rule, they must be taught techniques to measure compatibility (e.g., appimagelint and manual testing, in the future maybe also automated test frameworks such as OpenQA), and they must be shown methods how to increase compatibility with the least possible effort (I provided some examples above). A little anecdote from IRC: recently, a user was struggling to package a rather complex, OpenGL based software as an AppImage. They were lost in the docs, lost with tools like appimage-builder (which is not well suited for this kind of application, as @azubieta confirmed), they didn't know what to do and how to get started. With a little guidance from my side (with information we should write down to some guides some day, I guess), the user was able to get started with their AppImage. They found a little limitation within linuxdeploy which we quickly resolved. They then started optimizing once a working prototype existed. It's really not that hard. But what if we confronted such a user who is already frustrated with "NO NO NO you MUST support Ubuntu 18.04 RIGHT NOW"? It makes no sense. The user quickly understood the best practice and decided it was okay to violate it for now but try to satisfy it later in the process. Such a process can span over years, especially in open-source hobby projects. In this time, they're denied listing the AppImage within the catalog, even though it's not really their fault, and no other platform would ever impose such restrictions. We want to bring more people into making good AppImages. Good AppImages run on all the platforms they intend to support. They need to be tested, they require QA. QA is expensive, time consuming and complex. Economically, it makes sense to just support, e.g., only the latest Ubuntu LTS and above, because the limited resources are best spent testing those intensively, and the possible customer range doesn't use other systems (I guess this is a typical term in support contracts). P.S.: This reminds me a bit of that discussion around a "web of trust" for AppImages. This idea may have sounded interesting and promising at first. On a technical level, however, the idea was quickly proven to be bad, and the expectations were shown to be unrealistic. A lot of it is true for the binary compatibility check enforced on AppImageHub... It took me a lot of time and effort to demonstrate the issues in a way so that advocates of the idea could see and hopefully understand why web of trust is an obsolete technology, e.g., by citing the issues around the PGP WoT and comparing the proposal to this known-broken system that overall has never managed to come up to community's expectations. (Also, user feedback should never automatically be turned into a trust metric, look at all the fabricated reviews on all the online shops...) P.P.S.: Sorry for the wall of text. If I had another 2 hours of time, I could probably turn this into a blog post with improved readability. Putting together this replica required more an hour of my time already. I hope it's worth it, I hope this is being read by @probonopd. My previous statements do not seem to have been completely taken into consideration... |
|
Thanks for sharing your detailed thoughts @TheAssassin. Many good points. While I have read everything I can't respond to every sentence, but I'd like to address the main considerations.
When testing AppImages, you need some baseline to test against (unless we just rely on some linting tool and do no actual test). For very practical reasons, I think that the oldest still-supported version of arguably the most widely used desktop distribution is a (halfway) reasonable baseline for testing. While it is not ideal, I would not call it "random". Of course, a better baseline would be something like a LSB Desktop Test environment like it once existed but seems no longer maintained by the Linux Foundation. Authors of AppImages can (currently) ignore this "recommended" baseline since the AppImage spec does not mandate compatibility to certain versions of certain Linux distributions. Users of AppImages expect them to "just work" because (so goes the widespread, although technically incorrect, assumption) they are fully self-contained (like containers). Users are then frustrated when it doesn't "just work". A matrix like "Ubuntu >= 20.04, Debian >= bullseye, Fedora >= 35, ..." would add complexity and would not really help if you run a less comon distribution. My philosophy with the AppImage format has been to make it as easy as possible for users, even if it means additional burden for developers (e.g.,: "need" the very latest compiler? Then wait until all distributions can run software compiled with it.) Formats like Flatpak and Snap reconcile the authors' and the users' views by simply shipping private copies of everyhting ("runtimes"). So possibly therein lies a hint for what we should do - strongly recommend, or possibly even mandate, that AppImages should bundle everything (beside X.org and the kernel) that an application needs to run, just like containers do. The overhead is approximately ~~5-10 MB. And there are other downsides, as we know. But maybe it's worth the tradeoff? My point is: I don't see an easy solution, as every solution comes with tradeoffs. The length of your (and now also my) post is indicative of this. I'd just like to start a discussion around how we can nudge more developers into making AppImages with better binary compatibility right from the beginning, before they reach appimage.github.io. (Scratching my own itch: It's becoming too much work for me.) |
|
...and again: only for it to fail the test AppImage/appimage.github.io#2983 and eating up my time explaining I have been explaining this over and over and over again all those years. It has eaten hours and hours, if not weeks or months of my lifetime. Our tools need to do the explaining. |
|
Maybe something like we do in linuxdeployqt is a reasonable tradeoff. Users seem to understand it. |
|
@probonopd instead of cracking down on AppImage creators with restrictive rules, why not introduce a notification in AppImages to warn the user that "your system is too old"? After all, the technology needs to move forward, and so does bug fixes and support for new features. Using old libraries can lead to vulnerability risks. That's what system updates are for (btw I use Debian). I've tried different times to bundle Abiword (for example) from Debian Oldstable or Oldoldstable... the result is that X11 crashes. Maybe, I want the same app bundled into an AppImage because disk space usage of regular packages, it would be useful for me to save disk space this way, with my apps bundled from my package manager to an AppImage. This is my use case, as others have others... the use we make of AppImages is only for our needs. Think how many Arch Linux users love AppImages and can't have them because (as you always and repeatedly say) "they have to be built on top of the older and still supported Ubuntu LTS". Let the user choose, and likewise let both developers and packagers decide the minimum system requirements. See "Bottles", it's only available as a Flatpak! "OBS Studio"? All formats except AppImage. Right now I'm building an AppImage for OBS Studio based on Junest, the estimated size will be around 600MB (less than the one built by AppRepo for sure), I wanted to use Ubuntu 20.04 "Focal" as a base and I'm failing so many times... I would I could have asked you, but I already knew what you would say: "oldest Ubuntu LTS still supported, plus you need to work with the OBS team for an official build". Indeed, I would like to take advantage of it, let's talk about it. Official packages.. yes... but how long have you been using GNU/Linux? I guess a long time! You should know that many packages are distributed unofficially, Flatpak has them too! I sent you 10 PR on appimage.github.io for packages created by me and 10 times you told me to ask the software developer (and I did, got no response). I also sent you the PR for 0ad, also published on the official site of the project... you gave me the same answer, even though that AppImage wasn't mine. I want to thank you for inventing AppImages. AppImage is the coolest package format there is, and we all agree here... however, the only thing that made me sad is that you, as the creator, go out of your way to make them hated. We could have been stronger than Snap and Flatpak... and instead the creators of the distributions do everything to keep us out (and the worst thing is that they are right too)! Cheers. |
|
AppImages need to run not only on the greatest and latest systems. Because schools and companies (where the user wanting to run an AppImage is not a system administrator) are not always running the latest and greatest systems. AppImages that work only on the latest and greatest systems are next to worthless imho, because you cannot assume that they run "just about everywhere". Developers should always develop for the oldest system users still might use, not for the latest. This should be basic common sense, don't you think? |
Then either you are doing it wrong or you are running into a bad, bad bug that should be fixed. Applications that run on earlier versions of distributions should always continue to run on later versions. Or else a bug should be filed. |
|
I'm not saying ignore schools and companies, I'm just saying that developers should be free to distribute packages however they like. Too many rules nobody likes. Also, at the level of online resources, docker-like tools that can expect Ubuntu 18.04 to be used are rare and difficult to configure. If the biggest limitation of an Appimage is the host's GLIBC compatibility, let it use its own GLIBC. As you well know, I'm working on scripts to compile Appimages based on JuNest (Arch Linux) and the programs run on much older resources than we AppImage packagers try to run, normally. https://github.com/ivan-hc/ArchImage Here we don't even need to "guess" the packages and files that are missing, on the contrary we just have to eliminate the superfluous. See here, this is my version of OBS Studio https://github.com/ivan-hc/OBS-Studio-appimage , initially the package started with 650 MB of sizes, now is "only" 300 MB, and can be still smaller with some searches. All we have to do is enter the necessary parameters in the AppRun and add the files to be removed to the list, and everything will work perfectly, and without errors. This is the script I use to build it: https://github.com/ivan-hc/OBS-Studio-appimage/blob/main/obs-junest.sh And if it is too complicated to understand, I'va also a template with more details on how it works: https://github.com/ivan-hc/ArchImage/blob/main/sample-junest.sh In this way we can enshort the time of production of our packages and made them executable on every GNU/Linux distro with kernel version equal or higer than 2.6 NOTE: i started this project a few days after i wrote my previous message in this thread, so this is a brand new solution... I'll try to package all my AppImages this way, Abiword included. |
|
A downside of the JuNest (proot) method seems to be that it doesn't work on, e.g., FreeBSD. (Yes I can run some Linux AppImages on FreeBSD!) |
|
I know that AppImages can run on FreeBSD, but I've not tested ArchImages there. Thank you for the feedback. So I think this solution should be improved, that's why I turn to you. One problem I've found, for example, is that I can't open links from the ArchImage in the host's browser, but I don't know the variables needed to do this. On the other hand it is possible to set a default theme in the AppRun (see my script to build Bottles https://github.com/ivan-hc/ArchImage/blob/main/apps/bottles-junest.sh ) and perhaps extend it into a better command to use the system theme. Everything can be improved. |
|
@probonopd the AppImage doesn't work on FreeBSD due to proot, but does it work using other modes? Maybe you can put an "if" condition in the AppRun. |
|
How can I switch it to the other modes? |
|
JuNest works in three modes:
The AppRun is simple and brief and contains all the options needed to made the app run (quite) normally. The only thing that changes from other AppRuns is I talked with the creator of JuNest and him suggested to use |
|
What is the reason that your AppImages need JuNest to run the application? Why can' they be run directly without the need for JuNest? |
|
JuNest already knows all the environment variables needed to run the files installed into it, in this way we don't need to guess the name of the variable. Simple. |
|
@probonopd just uploaded Abiword https://github.com/ivan-hc/Abiword-appimage/releases/tag/continuous Download's sizes only 122 MB UPDATE: MPV https://github.com/ivan-hc/MPV-appimage/releases/tag/continuous Download's sizes 166 MB |
|
@ivan-hc I appreciate the effort and time you are putting into making AppImages. Maybe the time would best be spent to work directly with the upstream authors (who write software like OBS, Abiword, MPV, etc.) to help them make official and supported AppImages of their software. In general, I recommend to download applications only directly from the application authors and not from "random" third parties. |
|
@probonopd I don't have much say in the matter, I just try to buffer the needs of those who, like me, would like AppImage packages when the manufacturer doesn't commit to distributing their apps in different package formats, or worse still insists on forcing users to install alternative tools to obtain them (see Bottles). Look at Arch Linux users, they're always busy keeping their programs up-to-date and building the AUR, and the official team isn't as big as Debian or other distributions. You'll always find third-party software in the AUR, and yet that's where Arch Linux is so successful! And I tell you this as a Debian user. If you really want to know, I already had the opportunity to contact the authors of some apps in the past, several months ago, and I did it again a few days ago. And finally, for programs that require continuous and timely updates, it is more convenient to resort to a package manager command than to open the browser, browse the site, look for the download page and keep the usual version of the package until someone else it will say "hey, did you know there is a new 9.1 version of the Goofy program?", and you're still at 2.3. Because of this, AppImages have lost their "sex appeal," so to speak. It happened to me after years of using Avidemux, and that's why I wrote AM and AppMan, first for me, and now for everyone. I conclude by telling you that all this time I have been doing it alone, building "AM Application Manager" and "AppMan", and building Appimage packages by myself, because I was tired of waiting for developers to officially distribute packages and then cut them from production costs. Knowing how to pack them, I decided to do it on my own. Developers get tired of packaging for all platforms, and only waste time if an AppImage or .deb or .rpm doesn't work. Developers should improve their programs, while packagers should assemble packages. I'm developing solutions to keep updates of these programs alive even after my death (if Github Actions doesn't die before me). Should I wait for program creators to get AppImage packages? They won't wait for anyone, and I wont wait them, and if they want to shut us out, they always will. I won't be watching. I'll work on it from outside... but I'll do it! And I think that's just the way for software to survive. I will not allow AppImages to die unjustly. Cheers |
Many AppImages get made using too new ingredients (and not bundling everything), resulting in those AppImages not being able to run on all still-supported LTS releases of major Linux distributions.
Personally, I am sick and tired of having to explain over and over again that you should not generate AppImages that cannot run on at least all still-supported LTS releases of major Linux distributions. It is eating way too much of my time, and it is giving the AppImage format a bad reputation ("doesn't work as advertised").
We need to somehow prevent such AppImages from being created in the first place. The low-level AppImage creation tools should simply print an error message and refuse to continue. Similar to how linuxdeployqt refuses to produce such AppImages.
Reference:
The text was updated successfully, but these errors were encountered: