[Interest] Official linuxdeployqt ?
Konrad Rosenbaum
konrad at silmor.de
Tue Aug 9 18:58:52 CEST 2022
Hi,
On 09/08/2022 15:50, 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.
<rant excuse="sorry folks">
Not ever in my career have I used an IBM Mainframe. Doesn't mean it is a
bad machine... ;-)
I seriously used AppImage once, without even noticing: KDevelop 5 before
it was available in Debian. I just downloaded, chmod +x, run, happy.
Tried it again today to check the impact on my system - still happy.
(Single hidden FUSE mount, runs without any other impact, cleans itself
up after exit. No pre-install dependencies needed.)
As opposed to flatpak (tried with KiCAD): oops, no download. Find the
friggin' flatpak package, install it, why do I have to....? Enter some
obscure incantation to download the binary, be surprised by all the
dependencies that come with it. Start it and be horrified by the impact
it has on the system (dozens of mounts and processes). Be even more
horrified that it does not completely clean itself up after exiting the
program. Uninstall this horror show and compile the KiCAD dev branch
myself - that was much less painful to watch than flatpak.
Snap: similar horror show. Ubuntu decided to snappify my browsers
(Firefox and Chromium) without asking me (because, who in their right
mind asks me?). The first I knew about it was when a message popped up
that they needed update - just after I had updated everything with apt.
Ran apt again - nothing. Found out about snap after some screaming and
sobbing. Ran the extremely obscure incantation to update all snaps,
error because firefox is currently running - what the F**K? Sorry, if I
want Windows XP style updates, I'll install Windows XP. Some more
inspection of what snap does in the background has not increased my
fondness...
Debian and RPM: sure, fully integrated. Relatively easy to build. If
push comes to shove, you can even shoehorn all dependencies into one of
those packages and thus make it compatible with many OS versions, while
also making it compatible with the system installer. Granted, purists
will look at you as if you were something nasty stuck under their shoe,
but printer vendors have done far worse.
Tar: even easier and users that install external software can usually
handle it. The update path is a bit ...well ...nonexistent. It works as
long as you do not hard-code pathes.
</rant>
What you want to use very much depends on your target audience. Do they
need system packages, easy download, or even source preferred over
binaries? What distribution do they run and what is the preferred
mechanism there? There is no one answer.
All we can say for sure after all this discussion is: Qt is used on many
different styles of Linux distribution with at least as many preferred
package formats. Feelings seem to run a bit hot on that topic, so any
choice will p*ss off someone.
So after all of this it seems to me that the sanest choice would be to
just populate a directory hierarchy and let some other tool deal with
all the anguish and innuendo that comes with the (wrong) choice of
distribution package.
>
> 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.
Examples? All I've noticed is that Linux is now easy enough for users
that don't understand how to unpack a tar or how to sudo to a root shell.
> 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.
Correct.
> 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.
Why would they? The point of AppImage is that you DON'T need to put it
into the distro package store.
> Ubuntu will eventually abandon Snap just like they did UpStart.
...hope springs eternal... ;-)
> 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
That's Mate. Not Ubuntu proper.
> 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
BTW: repeating the same link four times does not make it any truer or
more prophetic.
Flatpak is a Debian package, so of course it turns up in all Ubuntus.
> 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.
Read my lips: not, going, to, happen.
The biggest strength of Linux is its flexibility - it can be used for
any kind of niche product and market by tuning it just a bit and
selecting different tools.
The biggest weakness is fools like us calling it all Linux instead of
giving each flavor a completely new name - that creates the illusion
that it should be the same. That's what they did right with Android - it
has a completely new name instead of an illusion of being another Linux.
It has been a while since someone complained they could not install
Debian packages on Android.
Obviously the single central repository is also not the criterion for
corporate IT - Windows has none either. Please keep searching and let me
know what else you find.
[hint: inertia]
[80% of rant cut, unexpected trigger...]
> 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.
Say what?
Flatpak has absolutely nothing to do with Docker. It just uses similar
APIs. FP is an alternative app distribution path with dependencies in
image files. It does not isolate the app from the system. Docker allows
easy deployment of server components (using image files) with dozens of
versions in parallel, hundreds of instances running in isolated
environments and some network magic to tie it all together.
Following your logic I proudly pronounce Apache to be a better FTP
server, because it uses the same socket APIs, just a slightly different
purpose. ;-)
> https://www.omgubuntu.co.uk/2022/02/ubuntu-mate-22-04-flatpak-support
Still not prophetic.
[cut...]
> 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.
It's a solvable problem:
What directories are used is found in /etc/ld.so.config - for cross
compilation you have a sysroot and look for etc relative to that.
Additional directories will be found by checking RPath and by simply
knowing where Qt is (e.g.: ask qmake).
Identifying libraries is easier to do by name - if you find it in one of
the ld.so.config directories it is a system lib, otherwise it is a
private lib. What target platform a binary has is relatively easy to
find out by checking ELF headers.
A linuxdeployqt program has to know about Qt internals and dependencies
anyway, because a lot of stuff is not directly linked, but looked up at
runtime.
It's not as trivial as ldd, but it is also not some kind of black magic.
That's why such a tool would be quite helpful.
Konrad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20220809/e2d1ae15/attachment.sig>
More information about the Interest
mailing list