You are not logged in.
Pages: 1
PKGBUILDs of source packages don't usually change. E.g: xournalpp-git on AUR has version of 1.1.1 and last updated in 2022, yet if someone makes package from source, it should have version of 1.1.3.
How do you keep up with packages that are built from source? If PKGBUILD isn't changed, any AUR helper will assume it's up to date.
Offline
How do you keep up with packages that are built from source? If PKGBUILD isn't changed, any AUR helper will assume it's up to date.
It's up to the packager which convention/command to use in order to create a git-package version, see:
https://wiki.archlinux.org/title/VCS_package_guidelines
As long as there is no change in source, deps etc. which would prevent a successful/functional build (thus would require changes to the PKGBUILD), it's fully up to you when to update your git-packages.
any AUR helper will assume it's up to date.
Some aur helpers have special options for VCS packages, check their readme/instructions.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Just run makepkg, it will either upgrade, or tell you there is no need to.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Just run makepkg
Is there an AUR helper command to go through all source-based packages?
Last edited by avidseeker (2023-07-17 19:06:03)
Offline
Yes, there are many - what it is depends entirely on the AUR "helper" being used. But this thread doesn't seem to be about "source-based" packages as (most of) these will get an incremented pkgver on the AUR when they are updated. Your first post seemed to be specific to VCS PKGBUILDs. In any case, not much of a "helper" is needed. A half a dozen lines of shell script will do:
# assuming aur sources are kept under ~/aur
for pkg in $HOME/aur/*; do
cd $pkg
git pull
makepkg -si
doneAlso note that your previous statement that "any AUR helper will assume it's up to date" is wrong. The exact opposite should be true. The only reasonable algorithmic approach to answer whether a VCS package may have updates is:
echo yesGiven that VCS packages can effectively always be updated, some AUR helpers put this process behind a command line flag like "--devel". But this is a bit silly as - again - simply attempting to run makepkg will determine whether or not there are actual updates available and act appropriately. So I'd argue a sane AUR helper would run makepkg on every VCS package every time the user runs an update. Of course I also don't think there are any sane AUR helpers ... so there's that.
Essentially many AUR helpers try to implement the following logic:
1. determine whether VCS package should be updated
2. if yes, run makepkg
3. given that we only ran makepkg when there was an update, the update will proceed
What they should do is:
1. don't bother checking / determining anything, just run makepkg
2. if there are updates they will be applied, if there aren't makepkg will stop
This is simpler, easier, and much much less error prone. Essentially it is a logical parallel to the "pythonic" approach of try/catch rather than test/if-passed-run, though in this case the "catch" aspect is already built into makepkg itself. So all the user (or AUR helper) needs to do is "try".
(sidenote: I'm not even much of a fan of python in general, but there are a few very good programming patterns that have flourished in the python world, and this is one of them).
Last edited by Trilby (2023-07-17 22:38:53)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
these will get an incremented pkgver on the AUR when they are updated...
"any AUR helper will assume it's up to date" is wrong
Oh, I get it. I was making this statement based on the behavior with
xournalpp-git, which in this case, should be flagged out-of-date. But according to AUR,
This seems to be a VCS package. Please do not flag it out-of-date if the package version in the AUR does not match the most recent commit. Flagging this package should only be done if the sources moved or changes in the PKGBUILD are required because of recent upstream changes.
Last edited by avidseeker (2023-07-18 15:54:36)
Offline
xournalpp-git ... should be flagged out-of-date
I highly doubt this. If the current PKGBUILD works, it is not out of date. If the current PKGBUILD does not work, then still flagging it out of date is most likely the wrong course of action, rather comment / contact the maintainer.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Pages: 1