Add a Linux system packaging backend #1106
Conversation
|
I gave it a test using your process above on Linux Mint 21.1 Vera, and got "doesn't know the system packaging format for linuxmint" error. If I specified ubuntu:jammy target then it all worked, and the resulting deb could be successfully installed and run. |
|
@philsuth Thanks! I've just pushed an update that should now include Linux Mint (and Pop! OS) identification; can you confirm if that now works for you at the packaging step? (re-running the briefcase |
|
I can confirm that after the update the packaging ran successfully on Mint 21.1. Very neat! |
|
I can confirm that it identifies my Ubuntu 22.04 correctly, the generated package can be installed and the application starts. |
I think it's a footgun because at some unknown point in the future, it will no longer produce a |
|
Targeting Arbitrary Architectures However, Docker allows running images for arbitrary architectures via (I'll try to move my out-of-scope ideas in to enhancement tickets sometime this week.) |
Can't argue with this as an idea. Although the vast majority of Linux installs are x86_64, it would be nice to be able to build a Raspberry Pi package from my x86_64 CI machine, for example.
👍 |
RHEL Build ReqsThe base image for Of note....this only isn't a problem for PySide6 App
I put together the list below based on the Qt's requirements for X11....and trial and error on I tried the same thing on Also, in case anyone finds it useful: Script to start Docker with X11 access#!/bin/bash
if [ -n "$1" ]; then IMAGE="$1"
else
#IMAGE="debian:bullseye"
IMAGE="ubuntu:jammy"
#IMAGE="linuxmintd/mint21.1-amd64"
#IMAGE="fedora:38"
#IMAGE="kalilinux/kali-rolling"
fi
XSOCK=/tmp/.X11-unix
XAUTH=/tmp/.docker.xauth
xauth nlist $DISPLAY | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -
docker run --rm -it -e DISPLAY=$DISPLAY -e XAUTHORITY=$XAUTH -v $XSOCK:$XSOCK -v $XAUTH:$XAUTH -v $(pwd):/local $IMAGE |
Agreed it doesn't hurt to be explicit; I've added gcc, make and pkgconf-pkg-config as explicit system requirements for RHEL base machines.
I'll add these to the briefcase template, but... "Alexa, how do you spell 'we don't want you to use Qt'?" :-)
It's worth noting that Fedora 38 hasn't been released yet; 36 and 37 are the only two officially supported releases. I don't know if that might have contributed to the problem. I'll have a quick poke to see if I can see anything obvious; however, I'm somewhat comfortable landing this without full PySide support, especially if (yet again) the issue is incompatibilities with PySide packaging. |
Update: It wasn't a fedora 38 problem :-)
@rmartin16 FYI. I'm about to land #1107, which will involve a bit of a merge; but won't change anything functional here. |
I think this may be more of a function of |
|
As a PoC, I updated the This mitigated the Nonetheless, I would expect this problem to potentially encompass any Python package that's bundling its own libraries. |
I mean - we can probably exclude all the app and app_packages folders - after all, they're supposed to be manylinux wheels, and if there are any dependencies, they should be being declared by As for the segfault - is there any other processing going on? I've discovered through AppImage and Deb packaging that manylinux wheels really don't play well if they're futzed with after being packaged. |
That's probably the best approach....at least for now. Additionally, though, this probably needs to be done for Although, that's a bit unfortunate because this auto-dependency magic that List of packages automatically pulled in
All of the And the helloworld PySide6 app properly launched from my |
I think that's my read as well - I've added both these lines in.
Yeah - that list is... a little enthusiastic, to my reading. There's a whole lot of GTK dependencies that definitely aren't needed. We might be able to get a better list from the actual Qt RPM packages...
Ok - I've added those lines in as well. I've also finisehd merging the build-list changes, so I think we're at |
|
On a vaguely related, but indepdendent note - OMG there's a whole lot of noise in the PySide package... Why the hell does a wheel contain all the example code and documentation?! There's some room for some major optimisation with a |
Yeah....with no dependencies listed for the PySide6 HelloWorld app, I was able to get it running after
ha, yeah, no joke; when we were trying to clean some things up for Flatpak in beeware/briefcase-linux-flatpak-template#14, I remember seeing somewhere a whole list of files and directories being deleted from PySide6 after installing the wheel....although, I can't find it now.... |
freakboy3742
force-pushed
the
linux-system
branch
from
e1bb02d
to
3828f9d
Compare
|
🎉 Thanks so much for all your testing and assistance on this @rmartin16. Couldn't have done it without you. |
Adds a generic "Linux System" packaging backend, with (for now) support for Debian and RPM packaging.
Fixes #1062.
Fixes #1063.
Refs #1064.
Testing tl;dr
To test this PR, on any Linux distribution, run the following at a shell prompt:
Accept the default values for all questions, then:
An app should start showing an empty window. Then run:
If you're on a Debian-derived OS, this should generate a
linux/helloworld_0.0.1-1~<your distro>.debfile that you can install. If you're on a Redhat derived OS, there will be alinux/helloworld-0.0.1-1.<distro tag>.x86_64.rpm. Arch derivatives will raise an error that the backend isn't supported at this point (patches welcome - see #1064).This is a rework of #1081. Instead of treating Debian packaging as a unique backend, it treats "native system packaging" as a distribution type, and adds
debandrpmas packaging formats. In future,pkgand other packaging formats could be added to satisfy other distro packaging.Even without packaging support, Arch users can use the create/build/run parts of the Briefcase experience. It also means that Docker isn't needed for the default builds - Docker is only needed if you want to package for a distro other than your current distro. For that reason, this PR modifies the default Linux backend to be this new backend.
There is a
linux-systembranch on briefcase-template, plus a new briefcase-linux-system-template for apps.To test this, clone the briefcase-template locally, then run:
(substituting the path to your template).
If you're on any Linux, you should then be able to run:
and see the running app.
If you're on a Debian- or RPM-based distro, you can run:
If you're on any other Linux distro, or macOS, and you have Docker, you can run:
to build a package for a specific distro;
ubuntu:jammyis the vendor and codename of any distribution that has a Docker image (so -debian:bullseye,ubuntu:focal, andfedora:37will also work).The packaging commands will drop a
.debor.rpmfile in yourlinuxdirectory, as appropriate. You can then runsudo apt install -f <name of deb pkg>orsudo rpm -i -f <name of rpm pkg>to install the app. On installation, the app should appear in your desktop menus.The code is fully tested and documented; there are two areas which might need more work:
Linux system identification. I've done what I can based on Docker and Parallels checks; this PR should identify any distro from Debian, Ubuntu, Linux Mint, Pop! OS, RedHat, Fedora, Centos, AlmaLinux, Arch or Manjaro. It may work on other distros; however, I'm limited by what I can test locally. I'm interested in any reports on the failure modes of these (or other) Linux distributions.
Non Toga apps. I haven't done a lot of testing for non-Toga apps yet. PySide apps appear to build without any additional build-time requirements; I'm not sure if there are runtime requirements (it appears like there may not be any). The good news is that the only changes here should be the list of system packages needed to compile and run those apps.
This PR also has a chicken-and-egg relationship with beeware/.github#14 - This PR won't include app verification tests in CI until the PR on .github has landed; but that PR can't land until Briefcase supports system packages.
PR Checklist: