Package Details: diun 4.26.0-3

Git Clone URL: (read-only, click to copy)
Package Base: diun
Description: Receive notifications when an image is updated on a Docker registry.
Upstream URL:
Keywords: diun docker helper
Licenses: MIT
Conflicts: diun-bin
Provides: diun
Submitter: enmanuelmoreira
Maintainer: enmanuelmoreira
Last Packager: enmanuelmoreira
Votes: 1
Popularity: 0.001741
First Submitted: 2022-05-01 20:44 (UTC)
Last Updated: 2023-09-30 23:11 (UTC)

Dependencies (5)

Required by (0)

Sources (3)

Latest Comments

Static_Rocket commented on 2023-10-10 03:25 (UTC) (edited on 2023-10-10 04:08 (UTC) by Static_Rocket)

@enmanuelmoreira feel free to take the following. It fixes all of the issues I outlined in my previous response.

Pastebin patch file because this is a larger than reasonable for a single comment:

neoninteger commented on 2023-09-30 01:18 (UTC)

I don't know how much of a problem this really is, but thought I should point out section 2 of the Arch package guidelines, most notably:

Packages should never be installed to /usr/local

What I think Static_Rocket meant was that, rather than moving the binary from /usr/bin to /usr/local/bin, the service unit should be patched to launch /usr/bin/diun instead of /usr/local/bin/diun.

I was going to say that, if you didn't want to set up patching infrastructure within your package, you could just commit the unit file to the AUR repository alongside the PKGBUILD. But it seems that the GitLab repository you're pulling the unit file from is controlled by you, so that might not be something you need to worry about. Its unconventional to pull small auxiliary files like this from external sources, but as best I can tell, you're not violating any rules or guidelines by doing so.

One more thing I noticed is that the package doesn't come with a template or default diun.yml. Given the nature of Diun and the fact that there isn't really a one-size-fits-all default configuration, this is probably fine. But it might be a good idea to signal to users of this package that a configuration file needs to be written. How you do this is up to you, you could output a message to the terminal on installation of the package, include a README file in the AUR repository, or leave a pinned comment here on the AUR page.

An example diun.install file has been provided for convenience, which can be specified in the install field of your PKGBUILD to output a message upon package installation. Its up to you whether or not you want to use it verbatim, roll your own or do something else entirely.

post_install() {
    echo 'No default configuration is included in this package. You must create'
    echo 'your own `/etc/diun/diun.yml` file following the Diun documentation.'
    echo 'See for more details.'
    echo ''
    echo 'Once the configuration is in place, you can start the Diun system'
    echo 'service or enable it to run on boot like with any other service, e.g.'
    echo '# systemctl enable --now diun.service'

Aside from these concerns, I think you've packaged Diun well and appreciate you being such an active member of the AUR.

Static_Rocket commented on 2023-09-29 04:39 (UTC) (edited on 2023-09-29 04:50 (UTC) by Static_Rocket)

@enmanuelmoreira , thanks, but there's a bit of an issue.

Service points to /usr/local/bin/diun but binary is installed to /usr/bin/diun

Also system service scripts belong in /usr/lib/systemd/system/ not /etc/systemd/system/

The executable bit should not be set on systemd service files

Sysusers and tempfiles can be used to setup the environment for that service to work correctly out of the box:

enmanuelmoreira commented on 2023-09-29 03:57 (UTC)

Added release 4.26.0 including diun systemd service

KarmaTag commented on 2023-09-28 12:49 (UTC)

Any chance of getting a systemd unit added to the PKGBUILD?