Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#64201 - Add safe way to get pkgver of VCS packages
Attached to Project:
Pacman
Opened by atemu (atemu) - Monday, 21 October 2019, 16:13 GMT
Last edited by Allan McRae (Allan) - Monday, 21 October 2019, 21:23 GMT
Opened by atemu (atemu) - Monday, 21 October 2019, 16:13 GMT
Last edited by Allan McRae (Allan) - Monday, 21 October 2019, 21:23 GMT
|
DetailsIf I wanted to know whether my VCS AUR packages are up-to-date, I'd need to download each one's PKGBUILD, let it fetch the specified sources, evaluate the `pkgver()` function and compare that with the currently installed version.
Downloading PKGBUILDs and the sources listed inside them should be safe operations but in order to get the `pkgver`, a function with arbitrary and generally untrusted code needs to be executed. Since the `pkgver()` function is mostly used in VCS packages which only require [a few distinct commands to determine the version](https://wiki.archlinux.org/index.php/VCS_package_guidelines#The_pkgver.28.29_function), it'd be nice if those were built into `makepkg`, so that they can be specified by the package maintainer in a simple (not to mention readable) manner and, more importantly, be trusted by the package user. |
This task depends upon
Closed by Allan McRae (Allan)
Monday, 21 October 2019, 21:23 GMT
Reason for closing: Won't implement
Monday, 21 October 2019, 21:23 GMT
Reason for closing: Won't implement
Well, that's kinda what I want to see changed.
>I don't see how this could possibly work.
Why not?
Sure there are a few distinct ways to tag your versions but you could offer trusted functions for the most popular ones (annotated/un-annoated), a fallback (revision based) and/or even add a way to safely specify a custom pattern and that'd cover most (if not all) of the packages that can't feasibly get version bumps from `.SRCINFO`.
The only way that could change is if every upstream agrees to use their VCS in exactly the same way and to structure their code in exactly the same way. Never going to happen.