[Interest] Official linuxdeployqt ?

[Konrad Rosenbaum]

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>