Re: [Interest] Official linuxdeployqt ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
Hi, CMake has since version 3.16 an extension for its file command, namely GET_RUNTIME_DEPENDENCIES<https://cmake.org/cmake/help/latest/command/file.html?#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 ?
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 ?
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 ?
> 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
[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