Package standards issue

[Elsie19]

Has the bug or similar already been reported?
No.

Describe the bug
https://github.com/louis77/tuner/blob/abb0272a4e70c99a60aea840ddcab19871b6b165/data/meson.build#L78

This line is causing issues on pacstall/pacstall-programs#6918, as we now use bwrap to sandbox the install, and the line is trying to modify files outside the sandbox. Could this be removed and done as a postscript?

[technosf]

This does in fact add to the general reserve of GSchemas and incrementally compiles them all when run in standalone builds:
You can do a meson install -C builddir and it will update your schemas. For 1.5.2, python was being used to call glib-compile-schemas, but to simplify I went all in on meson since 1.5.5. This works for flatpak builds (and as I mentioned, local builds) - I am not au fait with pacstall (is this an Arch based tool... pacman)?

Running custom install script '/usr/bin/glib-compile-schemas /usr/share/glib-2.0/schemas'
FAILED: install script '/usr/bin/glib-compile-schemas /usr/share/glib-2.0/schemas' exit code 1, stopped

From flatpak builds the equivalent is:

Running custom install script '/usr/bin/glib-compile-schemas /app/share/glib-2.0/schemas'
compressing debuginfo in: /__w/tuner/tuner/flatpak_app/files/bin/com.github.louis77.tuner

So probably the issue is the destination - /usr/share vs /app/share - /pp/share is the reference in the rest of the meson build.

LMK your thoughts @Elsie19

[Elsie19]

The issue is indeed the destination, as if you're familiar with $pkgdir from PKGBUILD, in our system, that is the only directory that a package can write to during installation, and the meson.build is trying to write to other directories outside the build sandbox.

I am not au fait with pacstall (is this an Arch based tool... pacman)?

https://pacstall.dev/ It's like the AUR + AUR helper but for Ubuntu!

[technosf]

Take a look at DEVELOP.md - You can change the meson destination:

meson configure -Dprefix=/usr

However there are some hardcoded references to /app in the manifest - I am wondering if Meson will do substitution there... I would think not, and that poss. there is a reference var that can be used to replace /app. Worst case scenario - we can have a pacstall manifest.

@Elsie19 Please play around with this and see what works.

[eli-schwartz]

The issue is indeed the destination, as if you're familiar with $pkgdir from PKGBUILD, in our system, that is the only directory that a package can write to during installation, and the meson.build is trying to write to other directories outside the build sandbox.

Specifically, $pkgdir is passed as:

DESTDIR="$pkgdir" meson install -C builddir/

You do NOT use:

meson configure --prefix="$pkgdir/usr"

since that would produce totally incorrect paths at runtime. But an appimage might configure with --prefix=/app, yes.

Meson provides gnome_mod.post_install(glib_compile_schemas: true) for this, which handles detecting glib-compile-schemas for you and also respecting DESTDIR.

You could also directly pass meson.add_install_script(..., skip_if_destdir: true) to have the same effect as gnome_mod.post_install, namely, that if DESTDIR is defined then the install script does not get run.

It is, in fact, forbidden to run glib-compile-schemas when using staged / DESTDIR installs, since if you did use it then every single distro package containing schemas would each install the same /usr/share/glib-2.0/schemas/gschemas.compiled file, and you would get file conflicts. Instead, the file is created/updated when merging the distro binary package onto an end user system, NOT when running meson install as part of creating the distro package.

[pan-mroku]

FWIW, #216 worked for me. I was able to update AUR PKGBUILD with that change. Otherwise it fails to package

[technosf]

Please lmk if this is still an issue otherwise I will close it out.