Re: [Interest] Official linuxdeployqt ?

[A . Pönitz]

On Wed, Aug 10, 2022 at 12:31:43PM +1000, Hamish Moffatt via Interest wrote:
> > 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.
> 
> 
> I have never used an AppImage in 25 years of Debian and Linux experience
> either. It sounds equivalent to downloading a random unsigned .EXE from a
> web site and running it. I prefer official deb packages, or OCI/Docker
> container images, or at least a proper third party deb (ideally in a
> repository).

Same for me, at least at home.

There are two or three items that I regularly compile from source but apart
from that, it's "if there's no .deb, it doesn't exist" for me.

Andre'
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Roland Hughes via Interest]

On 8/10/22 05:00, Konrad Rosenbaum wrote:



Not ever in my career have I used an IBM Mainframe. Doesn't mean it is a
bad machine...;-)
Well you should have because now it pays more than Qt work! I get 
roughly 3 calls per week on it and my blue box is way out of date. Just 
signed a $120/hr RTR for brown box work yesterday though. :-)



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.)




https://forums.linuxmint.com/viewtopic.php?t=336342
Post by karichen Dec 01, 2020 7:56 am and again at 9:46 am
Post by antikythera Dec 01, 2020 11:37 am

=
solution - run the questionably sourced appimage in firejail, snap and 
flatpak are already sandboxed by default. Casing point, if you use 
Thunderbird snap you have to enable printer access for it.


so yes, appimage do pose a bit more of a risk than other packaging 
formats without end users being aware of the need to run them in firejail.

=

I don't remember karichen's job exactly but that user was deploying 
Linux Mint on corporate desktops for a not tiny company. Two not short 
but measured responses from the corporate "there be viruses" world.


I quoted the entire antikythera post to point out what was and probably 
is still true. Flatpak is sandboxed by default, AppImage is not.


I snipped your tale of woe with both Snap and Flatpak because yes, naive 
developers that never went to college can turn off all sandboxing to 
"make it work" then release trash on their own Web site. In the early 
days of Snap that trash also made it into the repos. I've not heard of 
anything in Flathub that is signed and behaves in a non-sandboxed manner.



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.

Tar also walks on existing libraries.

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.


Qt isn't used on as many Linux platforms as one would like to believe, 
not anymore. There are some legacy packages that haven't ported to other 
libraries, but not much in the way of new development post FeatherPad 
after the licensing shenanigans. Most distros have dropped KDE as a 
supported desktop because of that.


So, for the legacy applications still using Qt on Linux some will be for 
developers, but most will be for "consumers." Even Wireshark is flatpak 
today.


https://flathub.org/apps/details/org.wireshark.Wireshark

I will let karichen's posts stand for the corporate world and basically 
mine. I don't care how awesome something claims to be. I will only test 
install it on a sacrificial machine that is not on my network then I run 
a full antivirus scan. Yes, I have Clamshell running on all my Linux 
machines.



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.
Not really, no. You are building on a 64-bit machine but cross compiling 
for 32-bit ARM so your application can run on a Raspberry Pi II. 64-bit 
ARM for a later PI or possibly a MAC. The RPM distro tree wants each 
library in its own directory. /lib for 32-bit /lib64 for 64-bit etc. 
Debian does it different.

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.


https://www.zdnet.com/article/linux-malware-attacks-are-on-the-rise-and-businesses-arent-ready-for-it/

https://jetpatch.com/blog/patch-management/rising-ransomware-trend-why-is-linux-suddenly-a-target/

Lots of chatter now where companies deploying Linux desktops are 
changing the GUI app sources to point to internal company maintained 
applications. This has been done for Windows for years in the 
corporate/medical device world. Joe Palluka can't install from the 
Microsoft Store but they can install from the company store. Usually has 
half a dozen IDEs and editors. A few "office" type things that help with 
the standard office package, etc.





Does any distro 

Re: [Interest] Official linuxdeployqt ?

[Thorsten Glaser]

On Wed, 10 Aug 2022, Hamish Moffatt via Interest wrote:

> I have never used an AppImage in 25 years of Debian and Linux experience
> either. It sounds equivalent to downloading a random unsigned .EXE from a web
> site and running it.

It is, with the added complication of mixing things of incompatible
licences (like GPL and OpenSSL) inside it. I’ve seen one, and I was
not impressed and I will continue arguing against this practice, in
favour of distro-specific packaging.

bye,
//mirabilos (both private-professionally as well as for $dayjob)
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Hamish Moffatt via Interest]

On 9/8/22 23: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.


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. 



I have never used an AppImage in 25 years of Debian and Linux experience 
either. It sounds equivalent to downloading a random unsigned .EXE from 
a web site and running it. I prefer official deb packages, or OCI/Docker 
container images, or at least a proper third party deb (ideally in a 
repository).



Flatpak offers signed builds and sandboxing. If you were going to build 
a deployment format into linux deployqt it would have to be a modern 
format that included signing and sandboxing.



regards

Hamish

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Roland Hughes via Interest]

Well,

It's certainly not "optimal" and I don't believe it should have a high 
priority. It will lead to many horrible hacks for people compiling 
32-bit on a 64-bit machine.


Roland

On 8/9/22 10:17, Alexander Dyagilev wrote:
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 implement.




--
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

Re: [Interest] Official linuxdeployqt ?

[Alexander Dyagilev]

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 
implement.



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 

Re: [Interest] Official linuxdeployqt ?

[Roland Hughes via Interest]

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 

Re: [Interest] Official linuxdeployqt ?

[Bernhard Lindner]

AppImages are a breeze. For both developer and user.

An easy to use Qt-provided tool for that purpose would be fantastic.

On Mo, 2022-08-08 at 18:03 -1200, Vadim Peretokin via Interest 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. 
> 
> It really is that simple; experienced and unexperienced users alike across 
> many
> different Linux distributions make it work.
> 
> Try to replicate that with snap or flatpak - you won't be able to without 
> messing in the
> terminal or relying on distro-specific distribution channels. Nothing beats 
> AppImage for
> a truly distro agnostic image distribution format, and I'm speaking from 
> having used it
> for years to distribute my software.
> 
> BR
> 
> On August 8, 2022, Vadim Peretokin via Interest  
> wrote:
> > On 8/8/22 16:09, Jörg Bornemann wrote:
> > > Mitch already pointed you to QTBUG-74940.  The biggest question 
> > > regarding a linuxdeployqt is: what exactly is the deployment format 
> > > going to be?  There's no standard way of deploying Linux applications. 
> > > There are many.
> > >
> > > The community contributions create AppImage packages.  That seems to 
> > > be a reasonable choice.  Other opinions?
> > 
> > 
> > Like Roland said, it has to be Flatpak. I haven't seen anyone talking 
> > about AppImage in years, and Snap is too Ubuntu-specific.
> > 
> > 
> > windeployqt doesn't package anything though, so should linuxdeployqt? 
> > macdeployqt only sort of does, with its dmg support.
> > 
> > 
> > Hamish
> > 
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Gruß, Bernhard

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Joerg Bornemann]

On 8/9/22 08:03, Vadim Peretokin via Interest 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.


Yes, it provides a similar experience like macOS app bundles.

What linuxdeployqt definitely must offer is copying libs, plugins, 
asssets etc. into a staging area like the other *deployqt tools.


Maybe creating AppImage packages is - like the creation of packages like 
RPMs - a job for tools like cpack, and we shouldn't bother with it in 
linuxdeployqt.  Even though the code already exists out there.


Creation of flatpaks and snaps are way out of scope.


Cheers,

Joerg
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Vadim Peretokin via Interest]

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. 

It really is that simple; experienced and unexperienced users alike
across many different Linux distributions make it work.

Try to replicate that with snap or flatpak - you won't be able to
without messing in the terminal or relying on distro-specific
distribution channels. Nothing beats AppImage for a truly distro
agnostic image distribution format, and I'm speaking from having used it
for years to distribute my software.

BR

On August 8, 2022, Vadim Peretokin via Interest  wrote:
> On 8/8/22 16:09, Jörg Bornemann wrote:
> > Mitch already pointed you to QTBUG-74940.  The biggest question 
> > regarding a linuxdeployqt is: what exactly is the deployment format 
> > going to be?  There's no standard way of deploying Linux
> applications. 
> > There are many.
> >
> > The community contributions create AppImage packages.  That seems
> to 
> > be a reasonable choice.  Other opinions?
>
>
> Like Roland said, it has to be Flatpak. I haven't seen anyone talking 
> about AppImage in years, and Snap is too Ubuntu-specific.
>
>
> windeployqt doesn't package anything though, so should linuxdeployqt? 
> macdeployqt only sort of does, with its dmg support.
>
>
> Hamish
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Hamish Moffatt via Interest]

On 8/8/22 16:09, Jörg Bornemann wrote:
Mitch already pointed you to QTBUG-74940.  The biggest question 
regarding a linuxdeployqt is: what exactly is the deployment format 
going to be?  There's no standard way of deploying Linux applications. 
There are many.


The community contributions create AppImage packages.  That seems to 
be a reasonable choice.  Other opinions?



Like Roland said, it has to be Flatpak. I haven't seen anyone talking 
about AppImage in years, and Snap is too Ubuntu-specific.



windeployqt doesn't package anything though, so should linuxdeployqt? 
macdeployqt only sort of does, with its dmg support.



Hamish

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Scott Bloom]

From: Benjamin TERRIER 
Sent: Monday, August 8, 2022 9:20 AM
To: Qt Interest 
Cc: Scott Bloom 
Subject: Re: [Interest] Official linuxdeployqt ?



On Mon, 8 Aug 2022 at 18:10, Scott Bloom 
mailto:sc...@towel42.com>> wrote:


On Mon, 8 Aug 2022 at 08:10, Jörg Bornemann 
mailto:joerg.bornem...@qt.io>> wrote:
On 8/4/22 19:42, Scott Bloom wrote:

> Is there a Qt supported linuxdeployqt comparable to the windeployqt?
>
> I found the 3^rd party version, but the command line args are very
> different.

Mitch already pointed you to QTBUG-74940.  The biggest question
regarding a linuxdeployqt is: what exactly is the deployment format
going to be?  There's no standard way of deploying Linux applications.
There are many.

The community contributions create AppImage packages.  That seems to be
a reasonable choice.  Other opinions?

It seems to me that how a Qt app is actually packaged/deployed is out-of-scope 
of a linuxdeployqt tool.

It seems macdeployqt actually build bundles, but windeployqt just copy files 
next to the .exe file.
IMHO a linuxdeployqt should just copy files, like windeployqt. Given the number 
of way to package apps under Linux, the actual packaging should be left to 
other tools.

BR

Benjamin

Honestly, I would prefer a different option all together.

I would like to be able to give the tool a shared library or an executable, and 
it returns a JSON stream of data.

Where the data would include any runtime dependencies + any other Qt 
dynamically bound package files with their appropriate directories.

Then the user (or cmake function) could read in the data, and copy or build the 
bundle as necessary.

Having the option to “list” the data vs “copy and build” the bundle/application 
directory would give a very powerful resultant tool

As to “how to package” linux, honestly I would assume it would just copy the 
files into the correct location relative to the executable/shared library sent 
in.

Scott

windeployqt does have --list and --json options
I never used them, but they should be able to provide exactly what you 
described.

Benjamin
I use them exclusively with my CMake integration, my point is I don’t need (and 
don’t see the need) for more than the list/json results.

Scott
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Benjamin TERRIER]

On Mon, 8 Aug 2022 at 18:10, Scott Bloom  wrote:

>
>
>
>
> On Mon, 8 Aug 2022 at 08:10, Jörg Bornemann  wrote:
>
> On 8/4/22 19:42, Scott Bloom wrote:
>
> > Is there a Qt supported linuxdeployqt comparable to the windeployqt?
> >
> > I found the 3^rd party version, but the command line args are very
> > different.
>
> Mitch already pointed you to QTBUG-74940.  The biggest question
> regarding a linuxdeployqt is: what exactly is the deployment format
> going to be?  There's no standard way of deploying Linux applications.
> There are many.
>
> The community contributions create AppImage packages.  That seems to be
> a reasonable choice.  Other opinions?
>
>
> It seems to me that how a Qt app is actually packaged/deployed is
> out-of-scope of a linuxdeployqt tool.
>
> It seems macdeployqt actually build bundles, but windeployqt just copy
> files next to the .exe file.
> IMHO a linuxdeployqt should just copy files, like windeployqt. Given the
> number of way to package apps under Linux, the actual packaging should be
> left to other tools.
>
> BR
>
> Benjamin
>
>
>
> Honestly, I would prefer a different option all together.
>
> I would like to be able to give the tool a shared library or an
> executable, and it returns a JSON stream of data.
>
>
> Where the data would include any runtime dependencies + any other Qt
> dynamically bound package files with their appropriate directories.
>
>
> Then the user (or cmake function) could read in the data, and copy or
> build the bundle as necessary.
>
>
>
> Having the option to “list” the data vs “copy and build” the
> bundle/application directory would give a very powerful resultant tool
>
>
> As to “how to package” linux, honestly I would assume it would just copy
> the files into the correct location relative to the executable/shared
> library sent in.
>
>
>
> Scott
>

windeployqt does have --list and --json options
I never used them, but they should be able to provide exactly what you
described.

Benjamin
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Scott Bloom]

On Mon, 8 Aug 2022 at 08:10, Jörg Bornemann 
mailto:joerg.bornem...@qt.io>> wrote:
On 8/4/22 19:42, Scott Bloom wrote:

> Is there a Qt supported linuxdeployqt comparable to the windeployqt?
>
> I found the 3^rd party version, but the command line args are very
> different.

Mitch already pointed you to QTBUG-74940.  The biggest question
regarding a linuxdeployqt is: what exactly is the deployment format
going to be?  There's no standard way of deploying Linux applications.
There are many.

The community contributions create AppImage packages.  That seems to be
a reasonable choice.  Other opinions?

It seems to me that how a Qt app is actually packaged/deployed is out-of-scope 
of a linuxdeployqt tool.

It seems macdeployqt actually build bundles, but windeployqt just copy files 
next to the .exe file.
IMHO a linuxdeployqt should just copy files, like windeployqt. Given the number 
of way to package apps under Linux, the actual packaging should be left to 
other tools.

BR

Benjamin

Honestly, I would prefer a different option all together.

I would like to be able to give the tool a shared library or an executable, and 
it returns a JSON stream of data.

Where the data would include any runtime dependencies + any other Qt 
dynamically bound package files with their appropriate directories.

Then the user (or cmake function) could read in the data, and copy or build the 
bundle as necessary.

Having the option to “list” the data vs “copy and build” the bundle/application 
directory would give a very powerful resultant tool

As to “how to package” linux, honestly I would assume it would just copy the 
files into the correct location relative to the executable/shared library sent 
in.

Scott
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Roland Hughes via Interest]

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

Re: [Interest] Official linuxdeployqt ?

[Marius Kittler]

Am Freitag, 5. August 2022, 18:16:53 CEST schrieb Scott Bloom:
> Unfortunately both of these solutions (runtime dependencies and static
> build) only solve the staticly bound dynamically loaded DLLs
 
That's not true. A static Qt build also has plugins in form of static 
libraries and you'll have to decide when building/linking your app which 
plugins to link against (which is not a big deal). I haven't used 
`GET_RUNTIME_DEPENDENCIES` myself but I would assume if you specify all plugin 
targets you need as `MODULES` it'll take those dependencies into account as 
well.



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Benjamin TERRIER]

On Mon, 8 Aug 2022 at 08:10, Jörg Bornemann  wrote:

> On 8/4/22 19:42, Scott Bloom wrote:
>
> > Is there a Qt supported linuxdeployqt comparable to the windeployqt?
> >
> > I found the 3^rd party version, but the command line args are very
> > different.
>
> Mitch already pointed you to QTBUG-74940.  The biggest question
> regarding a linuxdeployqt is: what exactly is the deployment format
> going to be?  There's no standard way of deploying Linux applications.
> There are many.
>
> The community contributions create AppImage packages.  That seems to be
> a reasonable choice.  Other opinions?
>
>
It seems to me that how a Qt app is actually packaged/deployed is
out-of-scope of a linuxdeployqt tool.

It seems macdeployqt actually build bundles, but windeployqt just copy
files next to the .exe file.
IMHO a linuxdeployqt should just copy files, like windeployqt. Given the
number of way to package apps under Linux, the actual packaging should be
left to other tools.

BR

Benjamin
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Jörg Bornemann]

On 8/4/22 19:42, Scott Bloom wrote:


Is there a Qt supported linuxdeployqt comparable to the windeployqt?

I found the 3^rd party version, but the command line args are very 
different.


Mitch already pointed you to QTBUG-74940.  The biggest question 
regarding a linuxdeployqt is: what exactly is the deployment format 
going to be?  There's no standard way of deploying Linux applications. 
There are many.


The community contributions create AppImage packages.  That seems to be 
a reasonable choice.  Other opinions?



Also, is anyone on the Qt side, create a CMake function for this?

Where inside CMake, you could call “DeployQt(  )” and it would 
find all the dependencies and create a list of files in cmake etc


We have this CMake API in tech preview that adds the *deployqt calls as 
installation step.  See 
https://doc.qt.io/qt-6/qt-generate-deploy-app-script.html


However, Linux is not supported due to the lack of linuxdeployqt.


Regarding CMake's GET_RUNTIME_DEPENDENCIES: I'm with Scott here.  This 
solves only part of what the *deployqt tools do.


--
Jörg Bornemann | The Qt Company
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Cristian Adam]

Hi,

CMake has since version 3.16 an extension for its file command, namely 
GET_RUNTIME_DEPENDENCIES.

I used it for Qt Creator to deploy all dependencies on Windows, Linux, macOS 
from CMake.
As it turns out Qt Creator already had python script for deployment, and the 
CMake only solution got sacked at
https://codereview.qt-project.org/c/qt-creator/qt-creator/+/322646

It took part of MSVC, or MinGW (both GCC and LLVM flavors) C++ runtime DLLs, 
but that's more on the Windows side.

Alternatively, you can do a static build and forget about deployment issues 

Cheers,
Cristian.


From: Interest  on behalf of Scott Bloom 

Sent: Thursday, August 4, 2022 7:42 PM
To: interest@qt-project.org 
Subject: [Interest] Official linuxdeployqt ?


Is there a Qt supported linuxdeployqt comparable to the windeployqt?

I found the 3rd party version, but the command line args are very different.



Also, is anyone on the Qt side, create a CMake function for this?



Where inside CMake, you could call “DeployQt(  )” and it would find all 
the dependencies and create a list of files in cmake etc



Scott
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[EXT Mitch Curtis]

Nothing official; see https://bugreports.qt.io/browse/QTBUG-74940.

From: Interest  on behalf of Scott Bloom 

Date: Friday, 5 August 2022 at 01:44
To: interest@qt-project.org 
Subject: [Interest] Official linuxdeployqt ?
Is there a Qt supported linuxdeployqt comparable to the windeployqt?

I found the 3rd party version, but the command line args are very different.

Also, is anyone on the Qt side, create a CMake function for this?

Where inside CMake, you could call “DeployQt(  )” and it would find all 
the dependencies and create a list of files in cmake etc

Scott
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Scott Bloom]

I already have a cmake fuction I use for Qt deployment for windows and mac, but 
without the linux deploy application, I have nothing for linux

Scott

-Original Message-
From: Samuel Gaist  
Sent: Thursday, August 4, 2022 12:05 PM
To: Scott Bloom 
Cc: interest@qt-project.org
Subject: Re: [Interest] Official linuxdeployqt ?


> On 4 Aug 2022, at 19:42, Scott Bloom  wrote:
> 
> Is there a Qt supported linuxdeployqt comparable to the windeployqt?
> 
> I found the 3rd party version, but the command line args are very different.
> 
> Also, is anyone on the Qt side, create a CMake function for this?
> 
> Where inside CMake, you could call “DeployQt(  )” and it would find 
> all the dependencies and create a list of files in cmake etc
> 
> Scott
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

Hi Scott,

I can’t answer for the former but for the latter I had some WIP for macdeployqt 
that you can find here:

https://codereview.qt-project.org/c/qt/qttools/+/182317

I should revisit that but in the mean time it might already help.

Cheers

Samuel
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Official linuxdeployqt ?

[Samuel Gaist via Interest]

> On 4 Aug 2022, at 19:42, Scott Bloom  wrote:
> 
> Is there a Qt supported linuxdeployqt comparable to the windeployqt?
> 
> I found the 3rd party version, but the command line args are very different.
> 
> Also, is anyone on the Qt side, create a CMake function for this?
> 
> Where inside CMake, you could call “DeployQt(  )” and it would find 
> all the dependencies and create a list of files in cmake etc
> 
> Scott
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

Hi Scott,

I can’t answer for the former but for the latter I had some WIP for macdeployqt 
that you can find here:

https://codereview.qt-project.org/c/qt/qttools/+/182317

I should revisit that but in the mean time it might already help.

Cheers

Samuel


signature.asc
Description: Message signed with OpenPGP
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest