[Interest] Official linuxdeployqt ?

Alexander Dyagilev alervdvcw at gmail.com
Tue Aug 9 17:17:40 CEST 2022

I think that an optimal solution (and a pretty fit for me) would be for 
the linuxdeployqt to just deploy all the necessary files next to the 
specified binary.

It's up to a developer what to do next with all the files.

Of course, linuxdeployqt can also support (optionally) any number of 
various packages. But this should be optional and has a less priority to 

On 8/9/2022 4:50 PM, Roland Hughes via Interest wrote:
> On 8/9/22 05:00, Vadim Peretokin wrote:
>> Just to correct some biases here, in my opinion as a software publisher
>> AppImage is still the simplest way for a user to run your app.?
>> To get Mudlet (a FOSS text games client) all you need to do is go to
>> https://www.mudlet.org/download, download the .tar, right-click to
>> extract it and double-click to run.?
> Not to discount your experience, but I've been in IT almost 40 years 
> now. Not once in my career have I ever used an AppImage. I have used 
> Debian, RPM, Snap, and Flatpak.
> Most companies and many Linux distros have started making it more 
> difficult for someone to "just download and install from a Web site" 
> because Malware is everywhere.
> When your OpenSource project includes the scripts to make a proper 
> Debian or RPM package, you dramatically increase the odds of getting 
> your package into the actual distro repos. Does any distro actually 
> put AppImage files in their repo? I'm asking. I have never heard of it 
> but that doesn't mean there isn't some obscure distro doing that.
> Ubuntu will eventually abandon Snap just like they did UpStart.
> https://www.phoronix.com/news/MTYwNDE
> Ubuntu has a history of bad ideas, Unity not even being the worst.
> In fact, Ubuntu has already started their migration away from Snap by 
> installing Flatpak out of the box in Ubuntu Mate 22.04
> https://www.omgubuntu.co.uk/2022/02/ubuntu-mate-22-04-flatpak-support
> Why? Because the Linux distros that matter, some of them YABUs 
> themselves have all integrated Flatpak.
> https://www.omgubuntu.co.uk/2022/02/ubuntu-mate-22-04-flatpak-support
> You have to understand where it is going to understand why. Arch based 
> distros tried to solve this problem in their own way years ago.
> The Linux world demands a single trusted vetted repository. Then Linux 
> can seriously be considered for corporate desktops. It already has 
> applications like TextMaker and OnlyOffice, etc. What it doesn't have 
> is a single trusted repository.
> What the Linux world currently has is a bunch of AGILE "developers" 
> hacking on the fly, trusting automated tests that either test nothing 
> or test the wrong thing, turning stuff into distro specific repos that 
> busts things all over. Ubuntu has pushed out updates that broke all 
> wifi networking for users. If your device couldn't support a hard 
> wired connection you couldn't fix it.
> Core run-time like C/C++ major changes or the not that long ago SSL 
> change trash things.
> I've argued for decades that DOS didn't do it wrong. Everything bound 
> into a single executable was the only way to maintain security and 
> stability. Here now we have the Linux world trying to not admit shared 
> libraries (forced out of necessity in the dual floppy days) were 
> always a bad idea. A high risk shortcut to resource limitations.
> The Linux, Windows, and MAC worlds refuse to fix the problem. They 
> keep dynamically linking and an update that should have no impact on 
> your application what-so-ever shoots it out of the saddle by replacing 
> one of your required libraries with an incompatible version.
> Snap wasn't the correct idea. Flatpak is. It's basically a better 
> Docker and now many distros are having their graphical application 
> installer use Flathub directly.
> https://www.omgubuntu.co.uk/2022/02/ubuntu-mate-22-04-flatpak-support
> This will increase, not decrease, as the cost and effort each distro 
> incurs trying to find "volunteers' to be "maintainers" and physically 
> maintaining their repo has gotten too high.
> Why do you think there are so many YABU distros? Someone wants a new 
> distro for something, they want stability, and they only want to 
> change a few things (usually packaged applications) for their distro. 
> That's how Linux Mint and so many others happened.
> The Linux world is moving towards Flathub being the one place all 
> applications exist. All of them allowed to be shown in the GUI 
> installers will have been vetted by someone at Flathub and have active 
> malware/virus scans run on them. This is the end to a LibreOffice 
> update jacking your favorite IDE or PDF viewer by installing an 
> incompatible library. It has the hope of security.
> No offense man, but anybody can get a .whatever URL and post an 
> downloadable package on it. We in the Linux world have been far too 
> trusting and burned too often by that. I know that I don't personally 
> run daily virus/malware scans on the Debian and RPM packages I have 
> posted. I just replace with newer versions often. Nothing says that 
> Russia/China/North Korea/insert-nation-here didn't slip in an plant 
> something.
> Today's users and companies are starting to "just use the GUI" to find 
> their applications. Maybe they won't find yours, but they will find 
> something close enough. There are thousands of games, text editors, 
> IDEs, and office packages. Almost all of what you need (perhaps all) 
> can be found on Flathub now.
> ---
> The "just copy" conversation.
> Been a while since I did anything meaningful with Qt because the 
> medical device and embedded systems world has mostly abandoned it. The 
> CopperSpice stuff I've been doing like the RedDiamond editor uses hand 
> edited CMakeLists.txt files. Not as horrible as it sounds.
> https://sourceforge.net/projects/reddiamond/
> Everything started with the one for the Diamond editor and everyone 
> just tweaks it for all applications. It copies all of the needed 
> libraries into the same directory as the executable. (You need to know 
> what you need and it only copies CopperSpice libraries, not base OS 
> libraries.) All of the plug-ins are in a subdir under the exe.
> This makes things incredibly easy after running LDD on the binary. You 
> can quickly create your script files to generate Debian and RPM 
> packages. I have some as part of that project for those who wish to look.
> Currently CopperSpice doesn't cleanly compile in the Flatpack world 
> where they don't want even the slightest warning. Supposed to get 
> fixed after they get Ubuntu 22.04 compilation warnings cleaned up.
> Eventually I will remove all of my Debian and RPM packages and just 
> have Flatpak. For any "consumer level" app, that's where myself and 
> those I speak with are all going. We can automatically be included in 
> distros that will give us access to millions of desktops. They don't 
> have to stumble into us on the Web.
> ---
> Any linuxdeployqt is still going to have significant issues with all 
> of those distros using /lib and /lib64 directories. Then you have to 
> deal with /lib-arm for cross compilation.

More information about the Interest mailing list