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
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
