Option to use `.nvchecker.toml` in AUR repository

[Freso]

It’s becoming a de facto standard to include .nvchecker.toml files at the root of Arch package repositories, and at least some AUR packages are adopting this as well. It would be handy if it would be possible to tell aur-auto-update to use this one so we wouldn’t have to essentially duplicate the nvchecker configuration.

I get that in the current form this would create a lot of overhead since the AUR git repositories are not cloned unless an update is available, so not sure how this would be implemented. I still wanted to leave a feature request in case there’s someone who can think up a clever solution. :)

[carlosal1015]

Hi @Freso maybe is an off-topic question, I've seen this pattern for package repositories in [core] and [extra], for example for python-textual, could you list some aur packages from different maintainers that has now this adoption.

In official repositories are unusual see .gitignore present , in other hand in AUR repositories I try to have .gitignore file as possible. In the below links, they claim that only PKGBUILD and .SRCINFO should be there, until now I didn't ever seen in an aur repository with nvchecker.

Another pattern in official repositories are folders for example for gpg keys with several .asc files, but in AUR there are not present.

• https://lists.archlinux.org/hyperkitty/list/aur-general@lists.archlinux.org/message/MOPSP2775K6L3WGXJ5XUXQ3VGGFIO3VE/
• https://lists.archlinux.org/hyperkitty/list/aur-general@lists.archlinux.org/message/CKVS6TOCBL6OSIKNAIQAN2RAUEORHW3G/

[Freso]

Examples of .nvchecker.toml:
obs-pipewire-audio-capture: AUR, git(, gitlab)
python-progress: AUR, git
electron25: AUR, git
ttf-sil-doulos: AUR, git

The keys/ directory structure only makes sense for packages that are using PGP/GPG signatures to verify packages and is specified in Arch Linux RFC 11. It is (slowly) getting adopted by AUR packages where it is relevant; e.g., pacman-static, firefox-extension-localcdn, and youtube-dl are a few that already have this structure.

About .gitignore: not everyone thinks they belong in AUR packages either, but they are still being recommended/highlighted in the AUR submission guidelines. I don’t usually add them to my packages, but I also don’t remove them if they already exist.

Also of note is the discussion/desire to be able to more smoothly move packages to and from AUR and official repositories – and keeping files such as .nvchecker.toml in AUR also helps towards this. :)

[carlosal1015]

Many thanks for the details. I appreciate a lot.

[Freso]

The script in #51 may be helpful towards this. Maybe an approach could be to check whether .nvchecker.toml has been updated when running a regular update and if so, convert-nvchecker-toml-yaml could be run on the new .nvchecker.toml to replace the <project>.yaml file?

[carlosal1015]

After 9 March I include in many packages .nvchecker.toml, will be nice only take this input file and in the future deprecate package-name.yaml. bin/convert-nvchecker-toml-yaml is nice 😄

[petronny]

After 9 March I include in many packages .nvchecker.toml, will be nice only take this input file and in the future deprecate package-name.yaml. bin/convert-nvchecker-toml-yaml is nice 😄

Removing the nvchecker field in pkgbase.yaml is possible. But we still need to save the other configurations like whether to run the build test and push to AUR (or just flag the package as out of date).

Maybe an approach could be to check whether .nvchecker.toml has been updated when running a regular update and if so, convert-nvchecker-toml-yaml could be run on the new .nvchecker.toml to replace the <project>.yaml file?

It will require some efforts and tricks. But I think it worths doing.

[petronny]

But we still need to save the other configurations like whether to run the build test and push to AUR (or just flag the package as out of date).

Second thought. We can create another account called AutoFlagBot. So adding AutoUpdateBot means to build and push, adding AutoFlagBot means to flag and adding them both means to build, push and flag when build failed.