feat(bundler): Add Pacman package support, closes #3728

[oowl]

What kind of change does this PR introduce?

• Bugfix
• Feature
• Docs
• New Binding issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes, and the changes were approved in issue #___
• No

Checklist

• When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
• I have added a convincing reason for adding this feature, if necessary

Other information

[lucasfernog]

Awesome PR as an Arch BTW user! Can't wait to take a look at it after v1 lands.

[oowl]

Hello, Anything I need to do for this pr?

[lucasfernog]

I didn't check it yet @attenuation we need to sort out how to include this - might be merged to a next branch.

[RubenKelevra]

Just a archlinux package maintainer chiming in here:

Yes, ArchLinux does have binary packages, but the amount of users who contributes them is very small. There are much more maintainer who are not "trusted" and thus only providing building instructions to the AUR.

This PR covers only using an local tauri app and create a binary for it and ship it as packaged binary.

It would actually be much better to have a tool which can generate a PKGBUILD from a tauri app, which fetches the tauri app's source via an url, fetches tauri as dependency and builds everything locally. This is something every AUR user can use.

Going this route does not block the generation of binaries for the repositories either, as repository packages are always meant to be built inside a chroot and be fully self-contained.

[nothingismagick]

It would actually be much better to have a tool which can generate a PKGBUILD from a tauri app, which fetches the tauri app's source via an url, fetches tauri as dependency and builds everything locally. This is something every AUR user can use.

Yes! This is so fundamentally important for proper package distribution. Thankyou for sharing your perspective!

[nothingismagick]

I can't test this on linux, but I think the idea is sound. Especially since its is proactive.

[RubenKelevra]

@nothingismagick wrote:

It would actually be much better to have a tool which can generate a PKGBUILD from a tauri app, which fetches the tauri app's source via an url, fetches tauri as dependency and builds everything locally. This is something every AUR user can use.

Yes! This is so fundamentally important for proper package distribution. Thankyou for sharing your perspective!

I'm happy to help, just mention me if there's anything you need to know to make sure I'm seeing this in time.

There's a PKGBUILD-proto-file for creating packages under arch.

I think the best practice would be that you can download any Tauri archive. Run a command and get a PKGBUILD generated for it.

A package maintainer would compare this to his current PKGBUILD make the necessary changes and build the package for the repository in a clean chroot.

I'll write a longer answer below how a generation could look like.

[RubenKelevra]

The build instructions, named PKGBUILD, in Arch are pretty straight forward. Tauri can simply generate the build script and let the arch tooling do the job of compiling the tauri app by reading the PKGBUILD files.

The reason for this is, the whole Arch User Repository is not in binary files, but in PKGBUILD files. So the pregenerated files would only need minor adjustments to be uploaded there by the maintainers. The packages for the binary repositories of Arch are also published by the maintainers as PKGBUILD files, and then build and distributed as binaries, too.

If there's a tauri-app stored for example in a .zip-archive, it the url to it would be stored in the source-array like this: source=("https://example.com/$pkgname-$pkgver.zip").

This will be extracted in the $srcdir, so as path it would end up in: $srcdir/$pkgname-$pkgver/.

And there the tauri app could be built.

It would be nice if the build-process could accept a general "package-root" variable where the files are placed, instead of putting them into the source folder under something like src-tauri/target/release/bundle/linux/packageroot

If that's not possible the package() { } section would look like that:

    cd "$srcdir/$pkgname-$pkgver"
    package_src='src-tauri/target/release/bundle/linux/packageroot'
    install -Dm 755 "$package_src/usr/bin/$pkgname" "$pkgdir/usr/bin/$pkgname"
    install -Dm 644 "$package_src/usr/share/applications/$pkgname.desktop" "$pkgdir/usr/share/applications/$pkgname.desktop"
    install -Dm 644 "$package_src/usr/share/icons/hicolor/256x256@2/apps/$pkgname.png" /usr/share/icons/hicolor/256x256@2/apps/$pkgname.png
    install -Dm 644 "$package_src/usr/share/icons/hicolor/32x32/apps/$pkgname.png" /usr/share/icons/hicolor/256x256@2/apps/$pkgname.png
    install -Dm 644 "$package_src/usr/share/icons/hicolor/128x128/apps/$pkgname.png" /usr/share/icons/hicolor/256x256@2/apps/$pkgname.png

In detail:

Field	Necessary	Detail
Maintainer	✔️	Name of the person who's responsible for maintaining this package (not the builder of the package per se). So probably necessary to ask the user for this.
pkgname=	✔️	Could be filled by jq '.package.productName' tauri.conf.json. Should never contain parts of the version as a number.
pkgver=	✔️	Version set in the tauri config file: jq --ascii-output --raw-output '.package.version' tauri.conf.json. Field can contain letters, numbers, periods and underscores, but not a hyphen (-).
pkgrel=	✔️	Is a arch internal version number for multiple package releases for the same version. Dependency fixes, build errors, etc.
epoch=	❌	Usually not needed.
pkgdesc=	✔️	Could be filled by jq '.tauri.bundle.longDescription' tauri.conf.json
arch=()	✔️	List of architectures. Should be something like arch=('i686' 'x86_64' 'armv7h' 'aarch64')
url=	✔️	e.g. https link to github project. Could maybe added as field to the tauri conf to have a source for that.
license=()	✔️	Just an array of the licenses of the package. Some Licenses need to be bundled into the the package, but for most it's enough to mention them there to fulfill the attribution.
groups=()	❌	Usually not needed.
depends=()	✔️	See docs: https://tauri.app/v1/guides/getting-started/prerequisites/#setting-up-linux
makedepends=()	✔️	Compilers and toolsets necessary only at compile time, like 'rust'
checkdepends=()	❌	Only if there are depencencies for an automatic testing function of the binary
optdepends=()	❌	Only necessary for optional depencencies for special functions
provides=()	❌
conflicts=()	❌
replaces=()	❌
backup=()	❌
options=()	❌
install=	❌	Should be filled by the package maintainer
changelog=	❌	Should be filled by the package maintainer
source=()	✔️	Should be filled by the package maintainer
noextract=()	❌
b2sums=()	✔️	Should be filled by the package maintainer
validpgpkeys=()	❌	Should be filled by the package maintainer
prepare() { }	❌	Prepare the build enviroment e.g. download stuff and apply patches. Docs: https://wiki.archlinux.org/title/Creating_packages#prepare()
build() { }	❌	Build the binary offline. Docs: https://wiki.archlinux.org/title/Creating_packages#build()
package() { }	❌	Move the files from the build enviroment to the package root to include them into the package. Docs: https://wiki.archlinux.org/title/Creating_packages#package()

[RubenKelevra]

@nothingismagick

So 99% can currently be extracted from the tauri.conf and written to a PKGBUILD-file to read it with standard arch linux tools.

This would require a conversion tool of some kind ... should I write one? I'm currently gravitating towards shellscript for this.

If you guys think that's fine I would submit a patch for that. :)

[oguzkaganeren]

Hi, it would be good if it is merged. Is there any reason to wait to merge the pull request?

[Narcha]

Suggested change

// unimplemented!();

[D3vil0p3r]

@oowl @lucasfernog @FabianLars could you please merge this PR? Currently on Arch Linux the !strip option in PKGBUILD seems to not work, making impossible to create an AppImage, and consequently creating a Tauri app package in AL.

[FabianLars]

Just reacting because i was pinged: I stopped working on Linux specific things some time ago so i keep somewhat ignoring this, sorry. Also, there was another approach/change proposed here and there was not enough discussion for me as a non-arch user to quickly decide which is better. But again, i didn't look at that PR much either, so maybe it is obvious...

Lastly, from what i can see NO_STRIP=true still works absolutely fine, though building appimages on arch is of course not that useful anyway since you can then only share your app with users of (updated) rolling release distros. -> That's probably why we didn't publish a hotfix that forces the NO_STRIP env var