[SOLVED] Running pkgver() before grabbing sources?

Aanok · 2018-06-11 20:43:32

There is a piece of software which is not distributed through a VCS that I would like to bundle into a self-updating ABS package requiring as little manual intervention as possible.

Version information and checksums can be recovered from an URL on the author's website returning a JSON file, which can be easily parsed in Python. Only knowing the version like so, it is then possible to determine the download link for the latest release, which comes bundled into a single AppImage file.

In other words, in order to know where to fetch source files it is required to first run pkgver() or some other such function. As far as I've been able to tell, this is not possible. Is that correct? Is there any way to dynamically fill in the contents of the source and checksum arrays?

The workaround I've thought of for the moment is to add curl or wget as makedepends and manually download the AppImage from within package(). This is clearly less than ideal for a number of reasons, like the fact it's adding an unnecessary dependency or that it requires verifying the checksums explicitly.

I am quite green to ABS packaging. Is what I'm trying to do (very unconventional automation) even a reasonable practice? Should I just bite the bullet and resolve to manually bump pkgver each time an update comes out?

Last edited by Aanok (2018-06-12 07:33:55)

Trilby · 2018-06-11 20:49:44

Aanok wrote:

The workaround I've thought of for the moment is to add curl or wget as makedepends and manually download the AppImage from within package().

Close, but definitely not in the package function. You can do that in prepare(), that's how VCS PKGBUILDs previously worked. So your "source" array would just be the JSON url. Makepkg will download that and it will be available to the prepare function which will then download the actual source.

Although I would first recommend you've exhausted all other options of finding a useable download url for the actual source that isn't hidden behind some json data.

What's the project / upstream url?

EDIT:

Aanok wrote:

There is a piece of software which is not distributed through a VCS that I would like to bundle into a self-updating ABS package requiring as little manual intervention as possible.

Actually, upon rereading, this is just a very bad idea, I suspect. The upstream source is at known urls, right? There is very little manual intervention needed to just increment the value of 'pkgver'. Use the pkgver variable in the source url.

Last edited by Trilby (2018-06-11 20:51:07)

Aanok · 2018-06-11 21:09:15

Trilby wrote:

Close, but definitely not in the package function. You can do that in prepare(), that's how VCS PKGBUILDs previously worked.

Ah, alright.

Trilby wrote:

Although I would first recommend you've exhausted all other options of finding a useable download url for the actual source that isn't hidden behind some json data.
What's the project / upstream url?

Upstream: https://cancel.fm/ripcord/
JSON: https://cancel.fm/ripcord/updates/v1 (checksums aren't there yet but are planned to be soon)

Trilby wrote:

The upstream source is at known urls, right? There is very little manual intervention needed to just increment the value of 'pkgver'. Use the pkgver variable in the source url.

Yeah that's what I'm not sure is clean about what I'm trying to do. It's just that updating pkgver is a (small) bother

Last edited by Aanok (2018-06-11 21:13:21)

loqs · 2018-06-11 22:42:12

curl -s https://cancel.fm/ripcord/updates/v1  |  jq '.versions.linux.normal[].file_version'

Trilby · 2018-06-11 22:45:44

loqs, that'd work for fetching the pkgver, but that wasn't really the question. The OP wants to use the output of a command line the one you posted in order to determine the url for the source.

respiranto · 2018-06-11 23:03:08

Aanok wrote:

It's just that updating pkgver is a (small) bother

That should be quite easy to automate on your side.

That's what I do for dict-foldoc [0] and all the dict-freedict-* PKBUILDs I maintain. Though the latter I do not automatically push to AUR (yet).

[0] https://aur.archlinux.org/packages/dict-foldoc/

loqs · 2018-06-11 23:03:27

Trilby I agreed with you about it not being a good idea for a none VCS package to try and auto update itself so I just provided a command to quickly get the new pkgver.
Then the PKGBUILD can be updated the new build tested and an updated pushed to AUR.

Trilby · 2018-06-12 00:23:01

Ah, thanks - I didn't get the context.

Aanok · 2018-06-12 07:32:46

respiranto wrote:

[0] https://aur.archlinux.org/packages/dict-foldoc/

Ah, there we go. My bad for not remembering a PKGBUILD isn't a magical incantation in some ad hoc language but just Bash, so if you put a command before declaring a variable... the command gets executed before declaring the variable
This is how to get rid of the curl/wget dependency.

But I see in general, as I suspected, what I'm trying to do is a bad practice. Indeed having a crontask or such that automatically checks for updates, updates the local PKGBUILD and notifies me there's something to check and push to the repo would be clean and only marginally heavier. What I would really like to avoid, in general, is having to manually check for software updates as maintainer or having to rely on out-of-date flagging. This would be a good compromise.

Thanks everyone

Trilby · 2018-06-12 10:01:48

Aanok wrote:

Indeed having a crontask or such that automatically checks for updates, updates the local PKGBUILD and notifies me there's something to check and push to the repo would be clean and only marginally heavier.

This is indeed the right way to automate this. In theory it wouldn't really take much scripting to make it 100% hands-off automated. A periodic job (cron job or systemd timer that runs every day or two) can get the json info, compare the version to the current PKGBUILD, if they match, stop. If they don't match, change the pkgver and checksum variables in the PKGBUILD, then run printsrcinfo and git commit and git push to send the changes to the AUR.

While this is possible, I'd advise against automating the very last step there. Your idea of having your script notify you is much better: you should test the new PKGBUILD before uploading it. If it really was just a version increment, the new PKGBUILD will work, and you can push the changes, but if something else changed, you'd need to work through that.

This really isn't any more work as - I assume - you'd want to update your package anyways.

eschwartz · 2018-06-12 11:05:16

Well, also see https://aur.archlinux.org/packages/diorite/ for how unattended updates can fail.

I've no clue how, but this person's cron job managed to delete the checksums instead of updating them, and they never noticed.

Arch Linux

#1 2018-06-11 20:43:32

[SOLVED] Running pkgver() before grabbing sources?

#2 2018-06-11 20:49:44

Re: [SOLVED] Running pkgver() before grabbing sources?

#3 2018-06-11 21:09:15

Re: [SOLVED] Running pkgver() before grabbing sources?

#4 2018-06-11 22:42:12

Re: [SOLVED] Running pkgver() before grabbing sources?

#5 2018-06-11 22:45:44

Re: [SOLVED] Running pkgver() before grabbing sources?

#6 2018-06-11 23:03:08

Re: [SOLVED] Running pkgver() before grabbing sources?

#7 2018-06-11 23:03:27

Re: [SOLVED] Running pkgver() before grabbing sources?

#8 2018-06-12 00:23:01

Re: [SOLVED] Running pkgver() before grabbing sources?

#9 2018-06-12 07:32:46

Re: [SOLVED] Running pkgver() before grabbing sources?

#10 2018-06-12 10:01:48

Re: [SOLVED] Running pkgver() before grabbing sources?

#11 2018-06-12 11:05:16

Re: [SOLVED] Running pkgver() before grabbing sources?

Board footer