Arch Linux User Repository

Quick note with regards to the case reported by @akrai - please see https://wiki.archlinux.org/title/Arch_User_Repository#Updating_packages. I was told in the AUR IRC channel that officially it is expected that users rebuild packages themselves if official package dependencies were updated, that includes this case where the Python version was bumped and nothing else changed.

In the future I will not bump this package for the given reason to continue following this guideline.

@jihem Got it, thanks for letting me know it's wrong there, it should be fixed now!

@icedream The missing dependency is actually on the fw-fanctrl package, not this one. Sorry for my useless comment.

@jihem python-jsonschema is already in the depends field though...?

Traceback (most recent call last):
  File "/usr/bin/fw-fanctrl", line 5, in <module>
    from fw_fanctrl.__main__ import main
  File "/usr/lib/python3.14/site-packages/fw_fanctrl/__main__.py", line 5, in <module>
    from fw_fanctrl.FanController import FanController
  File "/usr/lib/python3.14/site-packages/fw_fanctrl/FanController.py", line 6, in <module>
    from fw_fanctrl.Configuration import Configuration
  File "/usr/lib/python3.14/site-packages/fw_fanctrl/Configuration.py", line 6, in <module>
    import jsonschema
ModuleNotFoundError: No module named 'jsonschema'

python-jsonschema should be added as dependency to avoid this error.

okay understood, i'll follow the rebuild-detector mindset. Thanks!

@akrai The majority of the discussion was on the mentioned IRC channel - but tl;dr:

Bumping the rel can have negative side effects for people who hold back updates from official repositories, in parts or entirely (consider e.g. preventing issues in newer software versions from blocking a user from using the software - that has in fact recently happened with the mesa package for example). To be exact, it is entirely possible the triggered rebuild could then still be linking against an outdated dependency and not fix the issue you just had at all, and afterwards still won't rebuild again. Back to square one.

This discussion came up while I was actually asking for a best practice on how to automatically track Python package changes into this package by the way. So, to reiterate, while I can continue to bump rel when not in sync with Arch packages, it

1) introduces a negative effect for users who downgrade, partial upgrade packages or offset official repo updates altogether
2) adds extra effort for me to keep track of these packages unless I put that effort towards automating it entirely (automating it, I was explicitly told, is NOT a good practice at all for any AUR package)

It was also pointed out to me that the wiki page does explicitly mention a tool to detect when a package needs rebuilding (e.g. the rebuild-detector hook directly addressing dealing with this in pacman), so I'll forward that recommendation here as well. In fact, the understanding is an AUR helper should also be able to figure this out - whether that is currently practically the case is a separate question and it could be implemented as an upstream patch to the AUR helper.

I use yay myself and while I understand the appeal of letting the package trigger the rebuild, I have to put on the AUR maintainer hat here: Given that the suggestion is to not assume a user's state of system installations or the reasons for it, it is overall better to leave it to the user side (AUR helper or not) to trigger these rebuilds and reduce the effort on the package maintenance side of things or things quickly get a lot more complicated and less transparent on all sides.

sorry but i don't quite understand it. The wiki paragraph states that the user must rebuild it, yeah of course, but it doesn't state that the aur packages are forbidden to modify the pkgbuild in order to trigger an update of the aur helpers of people in order to automatically rebuild it as, with the official package being modified, the aur package no longer works until you rebuild it. So essentially, not triggering an update to people makes machines partially not up to date without warning people, which makes no sense and I don't see why anyone would want that. Also, you may or may not notice that you need to rebuild it. In this case, the package was no longer working and i noticed thanks to another package, fw-fanctrl-ui, that I happened to have installed and they added an icon for when fw-fanctrl service is not running properly. But you wouldn't notice that the service is not running if you didn't had that program installed and running, for example. Or the program could still be running but erratically due to old python packages or something.

Also, and lastly, the wiki states that it is not pacman's responsibility to keep AUR packages up to date, logically, as AUR is not supported, and in fact it is not pacman the program keeping AUR packages up to date, but AUR helpers like yay or paru, so nothing is being done wrong here as far as I know. I understand that the wiki states all of that just to let people know that they must not expect pacman to keep AUR packages up to date just using pacman, but people must manually or using external programs keep them up to date

So yeah, I don't quite understand the reasoning and I don't see that the wiki states to not help people auto update packages to stay up to date with official repos

Quick note with regards to the case reported by @akrai - please see https://wiki.archlinux.org/title/Arch_User_Repository#Updating_packages. I was told in the AUR IRC channel that officially it is expected that users rebuild packages themselves if official package dependencies were updated, that includes this case where the Python version was bumped and nothing else changed.

In the future I will not bump this package for the given reason to continue following this guideline.

its working again, thanks!

@akrai I bumped the package rel, I forgot that already built versions will result in the same package version being generated.