Arch Linux User Repository

License should go in $pkgdir/usr/share/licenses/$pkgname, not libbacktrace / ${pkgname%-git}. Convention is described at PKGBUILD.

The difference is of minor consequence, since it's the same project and the packages conflict. However, it could interfere with a script that checks licenses against installed packages.

As far as version number, sticking with r#.# is the correct decision. The 1.0 "release" and corresponding commit isn't well documented, so tracking revisions relative to it isn't really meaningful.

According to upstream, the software has an official version number: 1.0 (it is written in the upstream's README.md: "This is version 1.0.").

So I suggest to prepend the official version number to $pkgver (auto-retrieved via pkgver()). Then the =$pkgver in the provides array also makes sense.

Here is an example of a pkgver() function that does this parsing:

pkgver() {
  cd "libbacktrace"

  _ver="$(grep -E '[Vv]ersion [0-9\.]+' README.md | head -n1 | sed -E -e 's|.*[Vv]ersion ([0-9\.]+)|\1|' -e 's|\.$||')"
  _rev="$(git rev-list --count HEAD)"
  _date="$(git log -1 --date=format:"%Y%m%d" --format="%ad")"
  _hash="$(git rev-parse --short HEAD)"

  if [ -z "${_ver}" ]; then
    error "Could not determine version."
    return 1
  else
    printf '%s' "${_ver}.r${_rev}.${_date}.${_hash}"
  fi
}

And another issue:

License BSD is not a common license according to /usr/share/licenses/common/. Please explicitly install the license file into /usr/share/licenses/${pkgname}/.

Thanks for maintaining!,
regards.

Cannot build package:

==> Starting prepare()... patching file configure.ac patching file Makefile.am Hunk #1 succeeded at 84 with fuzz 1. patching file configure.ac Hunk #1 succeeded at 568 (offset 30 lines). The next patch would create the file libbacktrace.pc.in, which already exists! Skipping patch. 1 out of 1 hunk ignored ==> ERROR: A failure occurred in prepare(). Aborting...

Command 'makepkg' failed to execute.

Seems makepkg doesn't remove unrelated files from the repository before building. Anyway I have temporarily patched it so it won't fail for now.

@zed123: The 0002-Add-pkg-config-file.patch is no longer needed as it was taken care of upstream.

My PKGBUILD

Cannot build package:

==> Starting prepare()... patching file configure.ac patching file Makefile.am Hunk #1 succeeded at 84 with fuzz 1. patching file configure.ac Hunk #1 succeeded at 568 (offset 30 lines). The next patch would create the file libbacktrace.pc.in, which already exists! Skipping patch. 1 out of 1 hunk ignored ==> ERROR: A failure occurred in prepare(). Aborting...

Command 'makepkg' failed to execute.

While we are at it, why don't they add -ffat-lto-objects to devtools build flags?

I believe it's because it slows down the compilation when LTO is enabled, but is only useful when packages contain static libraries.

Also this option is ignored when LTO is disabled, so there is no harm in adding it when a package always produces at least one static library. Which is implied with staticlibs.

It's enabled in devtools: https://gitlab.archlinux.org/archlinux/devtools/-/blob/master/config/makepkg/x86_64.conf#L97

I reckon devtools is for building "official repository packages". And AUR packages aren't viewed as official (this impression comes from a bug wrangler).

Quoting from README.md:

This repository contains tools for the Arch Linux distribution for building and maintaining official repository packages

Perhaps just disable it then?

I would rather not bother with it unless truly necessary. If people want to build with LTO then they should setup their default build flags properly. Also IMO injecting the build flag package-by-package doesn't scale well and doesn't feel right.

While we are at it, why don't they add -ffat-lto-objects to devtools build flags?

It's enabled in devtools: https://gitlab.archlinux.org/archlinux/devtools/-/blob/master/config/makepkg/x86_64.conf#L97

On the other hand staticlibs is disabled in both pacman and devtools by default :p

@Chocobo1: Yes, I'm aware it's not enabled by default with pacman. However, it is with devtools. Perhaps just disable it then?

options=('!lto')

Please add export CFLAGS+=" -ffat-lto-objects" to the build() function to avoid mangling when stripping with LTO enabled.

No. LTO is not enabled by default: https://gitlab.archlinux.org/pacman/pacman/-/blob/v6.0.2/etc/makepkg.conf.in#L93

Use that flag for your own builds instead.