You are not logged in.
The icaclient AUR package is for the newest release of the Citrix Receiver remote desktop software. It is a pretty straightforward PKGBUILD from the binary tarball provided by the developers. The problem is that Citrix provides limited end user support and the binary tarball is closed source and often contains regressions (3 versions ago they broke smart card readers and the current version has SSL issues, the version in between was great). When the smart card regression happened, I created the icaclient19 package (which probably should have been named icaclient19.12 to follow the upstream version numbering scheme better). Prior to that someone created the icaclient-old package presumably to work around some other regression. Before creating an icaclient20.09 package, is there a better way to handle software that we want the version intentionally to lag behind until it is better tested but allowing for rapid updates for security issues and skipping buggy versions?
Offline
Pretty pointless in whole when you can just use git checkout to get and build whatever version of the package you want, isn't it?
Offline
I don't know. I can obviously choose when to rebuild an AUR package or I could add the package to "Ignorepkg" in pacman.conf or at the CLI, but that seems messy. The old version of the packages came about because of an icaclient specific issue and potentially users that use AUR helpers. Those who use AUR helpers, as usual, will be lost, but obviously the manual says to not use AUR helpers. The icaclient specific issue is that the download location changes when a package is no longer the current version which means that you have to edit the source array in the PKGBUILD to get old versions to build. This was apparently too difficult for some users so I made the icaclient19 package to help them out.
Offline
You can use git to retrieve an older version of the package.
example :
say you want the latest 19.x version of icaclient
You look up the changes list and see that was 19.12 .
On the commit page for that version[1] you see several hashes, copy the one listed behind tree .
Navigate to the folder where you git cloned the icaclient package.
execute git checkout tree_hash
check the files in the folder : they now have the same state as when icaclient package 19.12-1 was current.
If you run makepkg, you'll build icaclient 19.12-1 .
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
@Lone_wolf thank you, but I am clearly missing something. If I check out the old version, the PKGBUILD and associated files are in the same state as when 19.12 was current, but the world is not in the same state. Specifically the PKGBUILD says
source_url64="http:$(curl -L -silent 'https://www.citrix.com/downloads/worksp … atest.html' | awk -F 'rel=\"' '/linuxx64-/ {print $2}'| awk -F'"' '{print $1}'| sed '/^$/d' |uniq)"
but workspace-app-for-linux-latest.html now points to version 20.10. If I want to build 19.12, I need
source_url64="http:$(curl -L -silent 'https://www.citrix.com/downloads/worksp … -1912.html' | awk -F 'rel=\"' '/linuxx64-/ {print $2}'| awk -F'"' '{print $1}'| sed '/^$/d' |uniq)"
Now I agree that it is stupid to create a new package just to change workspace-app-for-linux-latest.html to workspace-app-for-linux-1912.html when I can hand edit the PKGBUILD file, manually download the source, or ignore the update, but some users have had issues.
Offline
If the newest version of the software is so buggy, maybe it should not be updated to the broken version?
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline