Arch Linux User Repository

I'd like to keep this in line with official packaging as mentioned before. It builds fine for me using makepkg. Of course you'll have to invoke it via makechrootpkg like official devs do as well due to the conflict or uninstall the package temporarily.

I'm disowning this package now so you can do whatever you like.

"This package builds just fine against the latest nginx package using the official makepkg and makechrootpkg packages. The version constraint is in-line with nginx module packages provided by official maintainers as stated before."

No it doesn't "build just fine". I sat here and tried it, I did the git clone makepkg rigamarole... and it refused to build as the version number check code you use is wrong.

Using FyreDraygg's patch, it worked correctly first try.

Given that you have two unrelated users who have found this bug exists, and both independently verified the fix, you ought just accept it exists. If it's building on your machine at all that is down to a peculiarity of your system.

"Yay does this because there are other AUR packages (not maintained by me) with provides=(nginx). Since I don't maintain these packages I can't help with that."

No, this is not true. First yay checks dependencies using your faulty version number check code. Your code fails, and then yay reasons that nginx does not satisfy the dependency, and so offers the alternatives.

When your erroneous code is replaced with FyreDraygg's correct code, it installs correctly using Yay.

This package builds just fine against the latest nginx package using the official makepkg and makechrootpkg packages. The version constraint is in-line with nginx module packages provided by official maintainers as stated before.

yay immediately decides that the arch package nginx does not meet the requirements and then pushes the user towards one of the many derivatives offered by the AUR.

Yay does this because there are other AUR packages (not maintained by me) with provides=(nginx). Since I don't maintain these packages I can't help with that. Ideally, yay would rebuild nginx-mod-rtmp against the latest nginx package so the system can be upgraded. It can do this by using makechrootpkg to do the rebuild (that is the proper way that is also used by official devs) or by temporarily uninstalling/breaking nginx-mod-rtmp (to be able to upgrade nginx and then just rebuild nginx-mod-rtmp with makepkg).

Actually I had plain nginx running happily before attempting to install this AUR package - heretically, using yay instead of just doing the git clone makepkg dance. As your package presents itself, yay immediately decides that the arch package nginx does not meet the requirements and then pushes the user towards one of the many derivatives offered by the AUR.

Now, at this point you're probably tempted to blame everything on yay, even though yours is the only AUR package I've ever come across to cause it to come up with erroneous dependency requirements...

But it would be besides the point, because even "properly" installing this AUR package by doing the git clone makepkg shuffle doesn't work, dying on a version number it cannot comprehend.

The cause for that is as FyreDraygg said, you wrote the version number check incorrectly. Their suggested replacement with one using awk instantly cured the problem.

I strongly suspect that if you implement FyreDraygg's fix, it will also fix the problem when an AUR helper is used.

the allegedly supported nginx packages.

I only compile this against the regular nginx package. Other packages may or may not work. That they are listed by the AUR does not mean that they are supported. It just means that whoever maintains these other packages added provides=(nginx) to the PKGBUILD - obviously without checking whether all nginx-mod-* packages support it or not.

As of 2026-04-01 this package no longer builds, …

It builds just fine for me against nginx=1.28.3.

What nginx package are you trying to build against exactly and what build error are you getting exactly?

citing unsolvable version error mismatch

Maybe you're just confusing an installation error with a build error here? Maybe you just need to rebuild this package against the update version of the nginx package you're using.

As of 2026-04-01 this package no longer builds, citing unsolvable version error mismatch with several of the allegedly supported nginx packages.

For example, currently installing angie provides 1.11.4-1, and this package throws a fit because it's not 1.11.3-1.

Would you suggest the helper ignore pkgrel …

Yes, just like pacman it should ignore the pkgrel if the dependency doesn't specify it. (If the dependency specifies the pkgrel it has to match of course.)

I think any helper that diverts from how pacman itself handles dependencies should be changed to be consistent with pacman.

it wouldn't hurt to rebuild this package one extra time

Then we need to rebuild this and all other nginx-mod-* packages on e.g. Perl or libxml2 rebuilds or when some other minor details of the package change. I would refrain from that and follow this note that was added recently to the official nginx package:

https://gitlab.archlinux.org/archlinux/packaging/packages/nginx/-/commit/feae9188663855c088dda57ca71686fd034f68c8#line_9b9baac1e_A20

I also see that other officially maintained nginx modules use the same versioning constraint as me:

https://gitlab.archlinux.org/archlinux/packaging/packages/nginx-mod-geoip2/-/blob/main/PKGBUILD?ref_type=heads#L38

So I would prefer to follow the official packaging and only change the versioning constrain inline with official packaging.

My own two cents on this would be that it wouldn't hurt to rebuild this package one extra time even if not strictly necessary if it meant better compatibility with all helpers out there. I had the issue with yay, which while not the best helper by any means isn't an exotic piece of kit. Furthermore, I don't think there's a lot of options to improve this on the helper side since the depends is asking for a strict version match. Would you suggest the helper ignore pkgrel or anything past an hyphen? I'd reason since this package should generally be built against by any version of nginx whatsoever, it makes sense to grab any and all version strings. To be clear, I'm not saying you're wrong. I might be biased by my own experience with it.

If Arch devs need to rebuild NGINX bumping pkgrel we probably don't need to rebuild this package, too. So I'm not sure whether that change would be most correct. Note that I haven't run into any issues using just pacman, makechrootpkg and my own helpers. So you're probably running into a limitation of some AUR helper which should probably be addressed by improving that helper.

Hi @Martchus and @XDjackieXD,

Thanks for maintaining this package. I wanted to report a dependency resolution issue caused by how the _nginxver is calculated in the package() function.

Currently, on line 31, the sed command strips everything after the hyphen: _nginxver=$(pacman -Q nginx | sed 's|nginx ([^-]).|\1|')

When the upstream nginx package has a pkgrel (for example, 1.28.1-1), this sed command truncates the version to just 1.28.1. Consequently, depends+=("nginx=$_nginxver") evaluates to nginx=1.28.1. This causes strict version matching to fail for pacman and AUR helpers (like yay), as they cannot resolve 1.28.1 against the installed 1.28.1-1, resulting in broken dependency errors or multiple provider prompts.

Proposed Fix: You can simply replace the sed command with awk to ensure pacman receives the exact Arch version string. Just change line 31 to: _nginxver=$(pacman -Q nginx | awk '{print $2}')

This captures the full version string exactly as pacman expects it, immediately fixing the dependency resolution for all users.

Could you please consider applying this fix in the next release? Thank you!