Package Details: libepoxy-git 1.5.4+20+g34ecb90-1

Git Clone URL: https://aur.archlinux.org/libepoxy-git.git (read-only, click to copy)
Package Base: libepoxy-git
Description: Library handling OpenGL function pointer management
Upstream URL: https://github.com/anholt/libepoxy
Licenses: MIT
Conflicts: libepoxy
Provides: libepoxy
Submitter: haagch
Maintainer: haagch
Last Packager: haagch
Votes: 9
Popularity: 0.000000
First Submitted: 2014-03-15 20:58 (UTC)
Last Updated: 2020-11-13 21:12 (UTC)

Required by (250)

Sources (1)

Latest Comments

1 2 Next › Last »

haagch commented on 2020-08-04 12:37 (UTC)

Huh, last time I touched this package was when it was still on aur4.archlinux.org. Still builds without modifications here, what do you mean? Just increasing the version number?

shoober420 commented on 2020-08-04 12:13 (UTC)

Please update your PKGBUILD to reflect the official in the main repository.

TingPing commented on 2017-02-06 17:38 (UTC)

Here is an improved PKGBUILD using the meson build system support recently added, also fixes the version: https://gist.github.com/TingPing/5da5a3051916a2daa3e049f7e16c968c

linkmauve commented on 2014-07-19 09:48 (UTC)

Hi, please add conflicts=('libepoxy'), or else installing libepoxy from [extra] won’t ask to remove this one.

Det commented on 2014-06-14 00:26 (UTC)

Right, but I thought Git would tag the minor versions itself? Not just the commit tag. Otherwise wouldn't that mean you'd have to tag every single commit for all Git packages? E: For example, with the original suggestion I currently get: $ git describe --tags --long | tr -d v | tr - . 1.2.8.gb2ae054-1 But the revision is actually pretty nice to know as well, so I'd probably just leave it as-is.

haagch commented on 2014-06-13 12:13 (UTC)

Now it's a compromise. :) I meant, this is using git commits AFTER 1.2.0 has been tagged, so development versions that can break at any time. Now if 1.2.0.g7422de5 has a breaking bug and I update to the next commit that fixes that bug, maybe it happens to have a hash 1.2.0.a123445 which is a lower "version", only when someone actually tags the next release version will the version really increase.

Det commented on 2014-06-13 12:00 (UTC)

I thought the next version would automatically be something like 1.2.0.1.g* or 1.2.1.g* (otherwise it doesn't really seem like Git's actually doing its job)? If not, then I still disagree on using the total number of commits as the major version just to get the incrementation okay. You could also say: $ echo $(git describe --long --tags | cut -d 'g' -f1)$(git rev-list HEAD --count).g$(git describe --always) | tr -d v | tr - . 1.2.0.204.g7422de5 or if the g-tag is really that useless: $ echo $(git describe --long --tags | cut -d 'g' -f1)r$(git rev-list HEAD --count) | tr -d v | tr - . 1.2.0.r204 These are both pretty complex, I know, but when you say "204.1.2.0" that's gonna mean "204th version, with minor release 1, and 2 bug fix releases". E: By the way, as per the previous request, git's missing from the makedeps.

1 2 Next › Last »