Arch Linux User Repository

@milouse it's probably better to put the path under /run/user/1000 ie. $XDG_RUNTIME_DIR

@oconnor663

PKGBUILD for keybase-bin-1.0.40_20180127012637+2887fffa7 seems to have a problem. The variable ${src_prefix} was used before it was defined.

Update: Fixed via https://github.com/keybase/client/pull/10363

The "prerelease.keybase.io" domain is indeed a bit of legacy in our packaging layout that we haven't gone back to clean up yet.

No offenses, it was just a suggestion.

It make sense when you know the process, but from a end user point of view the fact that binaries are updated on a daily basis is not documented anywhere, the only reference to versioning is the releases/tags on the github repository. There is also no "current release" reference on the keybase website, only install sections and link to the github repository. Another thing which mislead me: the binaries are downloaded from prerelease.keybase.io (which is also the case on the keybase website): I think this is why many of us where not understanding the releases flow and asked for stable releases (until now I was just thinking the website was outdated and still linking to prereleases)

This bin package is being updated by the upstream keybase release process, to correspond to the latest bin uploaded by the keybase team. It is therefore fulfilling the duty of all bin packages, to track, not "stable versions", but "binary releases from upstream". Which are not marked as betas or alphas or even RCs.

I am assuming for the sake of my sanity, that the keybase team are publishing the bin snapshots when they feel it is stable enough to, you know, publish as the official snapshots for all Debian and Fedora users ever. Given which, it seems to make sense to publish that as the unified release to all Linux platforms, including Arch Linux.

It is, after all, additionally linked and updated as the "current release" on the official website.

Speaking with my official TU hat on, I see no reason to get on their cases about this. In fact, if I were the package maintainer, I would endeavor to update just as frequently to the latest version being encouraged by upstream's primary download page...

I was going to suggest the same thing. The practice on packages is to have: - xxxx: src package tracking stable versions - xxxx-bin: binary package tracking stable versions - xxxx-git: src package updated regulary to track the master changes In your case, keybase is already taken, so maybe just: - keybase-bin tracking stable versions - keybase-git tracking master on daily basis

I agree with @jemadux. Is there any chance to track only the stable versions, i.e., the tagged versions on GitHub? Right now, I feel that we are tracking the master, and I would not like to install all the new hashes.

I am not sure if that is possible at all, but could we set up keybase-git to track master and keybase-bin to track only the tagged versions (v1.0.39 as of January 18, 2018)?