Arch Linux User Repository

it will compare to the AUR package version of (e.g. the current) 3.50.0.r13.gecffcc72-1 and try to install it (every time). Of course in the package build phase it generates the nightly tag, so it will build and install with that. This dance happening every time I run the package updates of the system.

That sounds like a problem with your AUR helper, it's normal for the VCS packages to be behind the "actual" version.

That tag seems to move, and thus the revision keeps resetting to 0, the difference being the commit hash only. This cannot be ordered

That's a good enough reason to exclude it I suppose.

Thanks for the info.

I don't follow, what's wrong with the tag being "nightly" (nightly.r0.gecffcc72)

That tag seems to move, and thus the revision keeps resetting to 0, the difference being the commit hash only. This cannot be ordered in that represents package development, so pacman is really confused about what's newer version, what's older version. This can bite twice:

1. if I install this package as it is posted, it will install with version nightly.r0.gecffcc72-1 and then every time I re-run, it will compare to the AUR package version of (e.g. the current) 3.50.0.r13.gecffcc72-1 and try to install it (every time). Of course in the package build phase it generates the nightly tag, so it will build and install with that. This dance happening every time I run the package updates of the system.

2. this nightly version number is not orderable because in most common cases it will be just r0 and the difference is the commit hash -> so newer releases which hash "below", I'd guess would not be updated (as Pacman would think that's a downgrade), and other such shenanigans.

I'm happy to hear if there's better way to do this, though I'm hard-pressed to think why anything else but the version number should be used.

I don't follow, what's wrong with the tag being "nightly" (nightly.r0.gecffcc72) instead of for example "v3.50.0" (3.50.0.r13.gecffcc72)?

I've added the change for now, to avoid an epoch later should we want to revert it.

The current setup picks up the "nightly" tag that seems to be used by the repo and continuously moved. The package should exclude that from the calculation, otherwise it will just keep suggesting new builds all the time (as the version becomes nightly.<blah>. This change worked well for me:

diff --git a/PKGBUILD b/PKGBUILD
index 745fb7e..eb501d7 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -17,7 +17,7 @@ sha256sums=('SKIP')

 pkgver() {
        cd "$srcdir/$_pkgname"
-       git describe --long --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g;s/^v//'
+       git describe --long --tags --exclude "nightly" | sed 's/\([^-]*-g\)/r\1/;s/-/./g;s/^v//'
 }

 build() {

AUR approach is great, but officially supported solution is based on homebrew.

There is a bazillion officially supported installation methods, not just brew.

You don't need to use the AUR, you can use extra repo.

If you want to help with documentation, you can update the upstream one to drop referring to anything to do with AUR and to just document installing from extra.

https://taskfile.dev/installation/

I believe I have fixed all of the raised issues and filed a deletion request for AUR/taskfile-gotask-git.

The executable is now named task-go.

EDIT: After further conversation, I have renamed the binary to go-task instead and requested this package to be merged into go-file-git, to be consistent with the other two already existing packages.

"unable to connect to github.com" is not a package problem.

I know it is not consistent to go with manual build, but Taskfile is GO based and GO is super easy to get running manually.

I think the reason this package is a bit troubled is because the effort on GO side is minimal:

go install github.com/go-task/task/v3/cmd/task@latest

That's what I ended up doing. Someone could take over the package and get it up to date, but then there is a conflict of the executable name with another package.

So, workaround for me has been to just install the application manually.

Fails to build

Building taskfile-git...
==> Making package: taskfile-git 2.8.1.r7.g7dcb3af-1 (Sat 18 Jun 2022 13:41:35)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Cloning task git repo...
Cloning into bare repository '/var/tmp/pamac-build-corey/taskfile-git/task'...
fatal: unable to connect to github.com:
github.com[0: 13.236.229.21]: errno=Connection timed out

==> ERROR: Failure while downloading task git repo
    Aborting...
Failed to build taskfile-git

Crandel's solution to change the PKGBUILD works perfectly. If only @kovetskiy could push an update :)