[Interest] Official linuxdeployqt ?

[Roland Hughes]

On 8/8/22 05:00, J?rg Bornemann wrote:
> The community contributions create AppImage packages.  That seems to be
> a reasonable choice.  Other opinions?

AppImage packages are high risk for malware (yes, it exists on Linux).

When building on Fedora RPM packages have gotten sooo simple. It used to 
be a darker than dark art, but now they have good tools.

Speaking as someone who has to create their own RPM and DEB packages 
here are the current industry trends.

DEB

Commercial .deb packages are still being built on Ubuntu 18.04. As long 
as you list "version >= x.y.z" everything installs on 18.04 up through 
22.04. You do have to bundle your own Qt libraries because __that__ is 
never the same anywhere.

This was not the case from Ubuntu 12.04 through 15.04. I even had a 
question here

https://stackoverflow.com/questions/53244436/compile-qt-program-on-ubuntu-18-04-which-will-run-on-ubuntu-14-04

some yutz gave the wrong answer about "backward compatibility" to then I 
came back and provided the answer that actually went into production for 
a huge U.S. chip maker and now I see some other yutz deleted that. Yes, 
it's a major problem any time the C/C++ compiler has an ABI change. Now 
that we no longer have to straddle 32 and 64-bit for the stuff we 
release the standard cheat employed by most is to install under /OPT

/opt/my_app/

executable and libraries at top level with exe tweaked to search local 
first. Your supporting resource or data files are placed on the next 
level down.

Purists moan and wail that it isn't properly split up under /usr but if 
you thump in a back-leveled library even if you put it in a clean 
directory, stuff will bust all over. You cannot insure the proper search 
order for each application.

Oh, you need to create a link in /usr/bin to your executable in your 
Debian post-install procedure. You must also delete the link in your 
Debian post-uninstall procedure.


RPM

Nice tools and documentation in the Fedora camp. Really simple to build 
RPM.

Right now people are installing Fedora 32 or 35 on a machine that has no 
connection to the Internet. Fedora is a rolling release so not cool as a 
primary build OS.

Again, everyone seems to be installing under /opt

What differs here is binary and library directories have their bits in 
the name. Well, you have /lib for 32-bit and /lib64 for 64-bit.


Flatpak

Personally I don't know ___anyone___ using AppImage. Most everyone has 
abandoned Snap too. Flatpak is the current migration path for all. Both 
AppImage and Snap had the problem of an 800 pound gorilla trying to fit 
into a tiny ballerina outfit. Flatpak steals a trick from Docker in that 
it utilizes layers.

https://www.flatpak.org/

There are currently only four primary build entities.

https://docs.flatpak.org/en/latest/available-runtimes.html

One of them is KDE, but given messages in the forum, is not complete Qt. 
Someone has been snivelling about the webengine/browser stuff not being 
there for quite a while now.

Perhaps AppImage and Snap added some kind of layering later in life, but 
I never saw it work. You always had to pull down every library. One of 
the limitless downfalls of CI/CD is that __everything__ gets built with 
a slightly different version  5.4.6 this week. 5.4.7 next week, etc. In 
the case of Qt, wxWidgets, and every other thousand-plus pound package 
this lead to glacial downloads.

I don't package any Qt stuff with Flatpak but from what I've heard the 
KDE SDK is more like a Ubuntu LTS that rarely gets updates. The first 
install pays a really high price and the rest are okay after that.

One of the more widely used ones is the Elementary SDK. It's based on 
Gnome (not Qt) and when you base on it you can appear in the Elementary 
AppCenter. Right now, for every other distro a user has to search for 
your flatpack via the distro Flathub interface.

I haven't done a deep study yet of which distros, but most new distros 
are following the path of Elementary. They are ditching .deb .rpm .arch 
etc. specific packages in repos for all but the core OS. Linux Mint 
supports Flathub in their Software manager.

Ah! Here's the clickbait list.

https://www.makeuseof.com/linux-distros-adopted-flatpak/

If you are going to build an official linuxdeployqt then you either 
carry on the traditional DEB/RPM packaging or you support what the 
entire industry has already moved to, Flatpak.

All of the non-embedded stuff I have is currently using traditional 
Debian and RPM packaging. I am moving everything that can be moved to 
Flatpak using the Freedesktop SDK.

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog