Package Details: aurman 2.22-1

Git Clone URL: https://aur.archlinux.org/aurman.git (read-only, click to copy)
Package Base: aurman
Description: AUR helper with almost pacman syntax
Upstream URL: https://github.com/polygamma/aurman
Licenses: MIT
Submitter: polygamma
Maintainer: polygamma
Last Packager: polygamma
Votes: 200
Popularity: 0.70
First Submitted: 2018-03-20 21:31 (UTC)
Last Updated: 2023-05-14 20:28 (UTC)

Pinned Comments

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 15 Next › Last »

polygamma commented on 2018-06-24 13:07 (UTC)

aurman depends on "expac" again.

eschwartz commented on 2018-06-24 07:21 (UTC)

Heads up -- expac 9 has now been tagged as a stable release.

Morganamilo commented on 2018-06-24 02:25 (UTC)

@Eschwartz thanks for clearing that up, I'd say add the r, epoch or not. Not that big of a deal though obviously, if it's not worth the effort then whatever.

eschwartz commented on 2018-06-24 01:58 (UTC)

I removed a bunch of comments (and the no-longer-needed replies) which were just providing help for GnuPG. Stop doing that. It's inappropriate.

Stop suggesting people break the package by messing with the dependencies. This is advice that moved on from being a waste of space, to being downright dangerous.

Morganamilo: on the topic of expac-git's version format, it uses the standard git describe format, but doesn't insert an "r" into the commit count. 8.2 is not the release tag, 8 is the release tag and 2 is the commit count. Yes, I agree the format is confusing, but it definitely doesn't break vercmp unless dreisner chooses to publish a major.minor release which is is unlikely since he's never done so before (and also knows the dangers of changing the versioning format in non-backwards-compatible ways).

The missing "r" is something that cannot be fixed anyway, without either adding an epoch or waiting until a stable release, since 9.r0.g${sha} is greater than 8.2.g{$sha}, while 8.r2.g${sha} is lesser.

Morganamilo commented on 2018-06-23 16:25 (UTC)

Oh well in that case it doesn't really matter then due to the .2 being more important than the commit.

Although depending on a specific commit doesn't really mean anything when it comes to alpm's vercmp.

I would still talk to falconindy about using the standard pkgver format though.

polygamma commented on 2018-06-23 16:20 (UTC) (edited on 2018-06-23 16:22 (UTC) by polygamma)

@Morganamilo I do not quite see your point, a new commit leads to "8.2.xxxxx"

Morganamilo commented on 2018-06-23 16:16 (UTC) (edited on 2018-06-23 16:18 (UTC) by Morganamilo)

While I am here though. The dependency on expac-git>=8.1.g5ae006f should probably be changed. vercmp just checks the ascii codes and can not tell which git commit comes after which. This means g5ae006f could change to become something that evaluated as less than the last commit.

Instead expac should be using the more standard 8.1.r100.g5ae006f versioning where you can then dep a specific revision expac-git>=8.1.r100

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 15 Next › Last »