Arch Linux User Repository

If the build fails:

• Clear your aur helper cache and SRCPKGDEST directory
• Rebuild in clean chroot 1
• If it still fails, use a paste bin 2 to show full build logs

There's a package build already which you can try out from my repo.

FAQ:

• The dependencies are correct. fmt and nlohmann_json are configured as subprojects for ease of development on my end, and it's only natural to statically link C++ projects, as ABI stability with exported C++ libraries isn't a thing (compared to C).
• If you think pod2man is missing, it's a configuration problem on your end. pod2man is part of the perl package, but in a perl-specific PATH handled by /etc/profile.d/perlbin.sh
• I'm only able to test auracle on i686 and x86_64, so that's what I'm willing to commit to in the PKGBUILD. If you want to build this on some other architecture, use makepkg -A. The "any" architecture is reserved for packages with architecture independent files (and compiled C++ is not).

Also, something to think about. Imagine situation like this:

Someone has some AUR packages installed on the system. But he/she prefers to keep packages build from AUR in the private custom repository so they can be updated automatically with pacman. The person has some scripts to automatically rebuild and upload to the repo all AUR packages he uses. The script automatically checks if there is new version of the package available in AUR. What happens with auracle-git right now? It's not being rebuilt by the script as both pkgver and pkgrel are the same as previously. Nothing has changed to tell the script there is new version or release of the package. So what he does? He clones the auracle-git AUR repo, manually bumps pkgrel, rebuilds and uploads new release to the repository as otherwise pacman wouldn't pick it up on system upgrade.

This sucks. And could be avoided with simple pkgrel build, which is totally proper thing to do in cases like that.

Not my package, but it's really annoying people don't understand the difference between version and release.

What you have just said is absolutely true, correct and expected.

The pkgrel bump is required only now, only for r290.d59f80b as this specific GitHub release results in broken shared dependencies in AUR if anyone has it already built and installed and it means the package has to be rebuilt. Once upstream commits new changes to the repo, makepkg would trigger pkgver() which will trigger automatic rebuild, so pkgrel should be lowered as having it set to 2 is not required anymore, as the version has changed.

So yes, users with already installed package could rebuild the package manually, and trigger manual update or maintainer could simply bump pkgrel and it would be picked up automatically by any AUR software manager / helper.

For me, the choice is obvious.

In your example the version was not changed so pkgver() was not run. When the version changes (meaning there was new commits upstream) then pkgver() is fired and it resets the pkgrel to 1.

But the pkgrel will be updated also when you rebuild the package.

No, it won't

Unchanged pkgrel:

Finished making: auracle-git r290.d59f80b-1 (Thu 24 Oct 2019 11:32:07 CEST)

Bumped pkgrel:

Finished making: auracle-git r290.d59f80b-2 (Thu 24 Oct 2019 11:33:46 CEST)

So again: Git package users are expected to follow upstream development and rebuild the package themselves when necessary. https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versioning

Not sure what I should get from it? The link points to arch packaging guidelines and there is no even mention about VCS AUR packages.

Following the link:

Package releases (i.e. PKGBUILD#pkgrel) are specific to Arch Linux packages.

So again: pkgrel are specific to packages, so they can be bumped on demand if required.

Here is more suitable link: https://wiki.archlinux.org/index.php/VCS_package_guidelines#Guidelines

Which says:

If the resulting package is different after changing the dependencies, URL, sources, etc. increasing the pkgrel is mandatory. Touching the pkgver is not.

And in auracle-git case, the resulting package is different as it's built using new version of shared library, so the pkgrel should be bumped.

That's my opinion.

But the pkgrel will be updated also when you rebuild the package. So again: Git package users are expected to follow upstream development and rebuild the package themselves when necessary. https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versioning

@falconindy: I'm not talking about pkgver, but about pkgrel. Yes, I'm aware the version will be automatically updated once there is new commit to the upstream repo. But before that happens, people will keep getting cannot open shared object file: No such file or directory messages unless they manually rebuild the package, so I still don't understand why pkgrel cannot be bumped. pkgrel is something local to the PKGBUILD, it's not affected by upstream changes.

@lisu_ml: This is a -git package, where the version does not reflect the current status anyway. Git package users are expected to follow upstream development and rebuild the package themselves when necessary. This way the version will automatically updated locally independently from the package version on the AUR.

That's not how this works. That's not how any of this works. Rebuild auracle yourself.

@falconindy: and what do you mean by that? It's a common practice to bump pkgrel when there is new version of shared library the package depends on. IMO, bumping pkgrel is not something difficult to do and can save other users' time as it would trigger automatic rebuild on their end. I don't understand what is the problem with simple pkgrel bump? Please elaborate.

@HiImTye "auracle sync -q | xargs auracle clone" should do it. Of course, it is a little bit more verbose.

is there an equivalent operation to cower -ud, or do we need to write a custom script to facilitate that functionality?