Arch Linux User Repository

For the past few years and up until last year or so, base-devel had been changed from a meta-package that pulls the base-devel packages as dependencies, into a package group that just allows you to batch install them as explicit, independent packages. When it was changed back to a meta-package, we users were supposed to manually install it (and optionally change the base-devel packages from explicitly installed to dependencies) so it would once again be responsible for managing its dependent packages. I think (but I could be remembering this wrong) that debugedit is a new dependency added in the last few months or so, so if you haven't installed the new base-devel meta-package, then it makes sense that debugedit wouldn't have been pulled in when it was added as a new dependency.

You can check to see if the base-devel packages (gcc, pacman, file, make, etc) are installed on your system explicitly or as dependencies; if they're explicit, then this is probably why.

You are correct @Nocifer. I've been installing AUR packages for years on this system but sure enough base-devel isn't currently installed. I didn't have to pull in any dependencies to install it. Apparently some how I managed to remove base-devel and debugedit but nothing else. I really don't know how that could have happened but it's fixed now so no need to spend anymore time on it. Thanks for maintaining this package.

That's probably because you're missing the base-devel package, which is a hard prerequisite for using the AUR.

@Nocifer - I think you should add "debugedit" as a build dependency. Without it I get this error:

/usr/share/makepkg/tidy/strip.sh: line 48: debugedit: command not found

@Garlo Nice find! I had experimented a couple of years ago with JWT but the then current libjwt package couldn't satisfy the dependency for some reason, so I had to leave it out and then promptly forgot all about it.

@grepfor You're right, I'm so used to using an AUR helper to manage AUR packages these days that the possibility of using an old(ish) copy of the PKGBUILD to perform a new installation without ever redownloading it never occurred to me. I guess there was a good reason I used to be against doing even minor updates without incrementing the pkgrel in the past, but apparently I've grown careless enough to break my own rule >.>

I satisfied libjwt dependency adding LIBJWT_LIBRARY variable to PKGBUILD file in this way:

    build() {
      cd ${pkgname}-${pkgver}

      cmake -DCMAKE_INSTALL_PREFIX=/usr \
        -DLIBJWT_LIBRARY=/usr/lib/libjwt.so \
        -DZM_CONFIG_DIR=/etc/${pkgname} \
        -DZM_CONFIG_SUBDIR=/etc/${pkgname}/conf.d \
        -DZM_RUNDIR=/run/${pkgname} \
        -DZM_SOCKDIR=/run/${pkgname} \
        -DZM_LOGDIR=/var/log/${pkgname} \
        -DZM_TMPDIR=/var/tmp/${pkgname} \
        -DZM_CONTENTDIR=/var/lib/${pkgname} \
        -DZM_CACHEDIR=/var/lib/${pkgname}/cache \
        -DZM_WEBDIR=/usr/share/webapps/${pkgname}/www \
        -DZM_CGIDIR=/usr/share/webapps/${pkgname}/cgi-bin \
        -DZM_WEB_USER=http .

      make
    }

@nocifer Imo, that reasoning does not capture a good chunk of real-world use cases for many AUR users, especially those who maintain several machines, and propagate packages locally via copying previously downloaded snapshot tarballs, rather than downloading a new one, unless the pgkrel has been updated.

When I locally propagate an AUR package from one host to others, I go to AUR and search the package name to see if the package version or pkgrel has changed relative to the installed version built from the original snapshot. If neither has changed, I propagate the package to other local target machines by just copying the existing snapshot tarball that I already have, expanding it on the target host and running makepkg there. This ensures that the builds across all my local hosts will start from an identical state.

Incrementing pkgrel would serve to alert users that downloading a new snapshot is warranted.

In this particular case, all snapshots downloaded prior to December 19 are effectively broken because they expose the end-user to silent variability of RtspServer as @synthead pointed out. Yet because the pkgrel was not bumped when that vulnerability was fixed, many people will simply propagate zoneminder locally via copying the previously downloaded snapshot tarball, thus propagating the broken PKGBUILD. Those users will not get the benfit of the fix until the pkgrel (or packager version itself) is bumped.

Just my 2c. I do appreciate the voluntary nature of the work that you and all the other Arch packagers do, and I hope that my comments do not discourage you from that.

@grepfor Basically, my thinking can be summed up with a quote from that Wiki link: ...fixes and additional features [...] that influence the resulting package.

The change is very minor in scope and it doesn't really influence the resulting package, because the commit that I used had already been the latest master for ~3 months (which is what the PKGBUILD had been pulling in as a dependency) and it contains only minor code formatting changes (which don't impact the binaries' behavior in the slightest), while the immediately previous commit is ~2 years old.

This means that at the time of the update, pretty much everybody would have already been using either a completely identical package (if they'd installed or updated this package within the previous 3 months) or a functionally identical package (if they'd opted out of updating their systems for longer than 3 months, but no longer than 2 years - the latter being an extreme corner case that I'm not really interested in supporting :P).

So if I'd incremented the pkgrel, the resulting update would be a non-update, either literally or functionally, and in both cases a complete waste of time and CPU cycles.

I could have waited for the next upstream release of Zoneminder and perform this change then, but ZM's releases these days are infrequent at best and this is a security-related fix of benefit to new users, but of no benefit to existing users; so I opted not to wait and instead update the PKGBUILD without incrementing the pkgrel, so new users can benefit from it as soon as possible, while existing users can enjoy their peace of mind.

@nocifer Out of curiosity for my own education, re your 2023-12-19 13:36 comment: I would like to understand why pkgrel was not incremented as a consequence of the PKGBUILD modification suggested by @synthead that you incorporated.

By my reading of https://wiki.archlinux.org/title/PKGBUILD#pkgrel it seems to me that pkgrel should have been incremented in a case like this, but perhaps my understanding is wrong and there is some advantage (unappreciated by me) in avoiding the incrementation. Please comment.

From my POV as a lowly user, integers are are free and there are lots of 'em, so why not bump the pkgrel just as a matter of routine administrative procedure, so that downloaders of snapshots having a given pkgrel can be assured that the corresponding PKGBUILDs are identical?

Not trying to pick a fight about it, just want to understand why it was done this way.

@synthead Smart solution, thanks. Implemented without changing the pkgrel.

@vinibali Sorry, I have never built ZM for anything other than x86_64. Hopefully you've managed to solve your issue in the meantime!