Package Details: libepoxy-git 1.2.25.r229.ga2a5190-1

Git Clone URL: https://aur.archlinux.org/libepoxy-git.git (read-only)
Package Base: libepoxy-git
Description: Epoxy is a library for handling OpenGL function pointer management for you
Upstream URL: https://github.com/anholt/libepoxy
Licenses: BSD
Conflicts: libepoxy
Provides: libepoxy
Submitter: haagch
Maintainer: haagch
Last Packager: haagch
Votes: 8
Popularity: 0.000000
First Submitted: 2014-03-15 20:58
Last Updated: 2015-06-16 14:39

Dependencies (4)

Required by (86)

Sources (1)

Latest Comments

linkmauve commented on 2014-07-19 09:48

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

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.

Det commented on 2014-06-13 13:56

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 release for all Git packages?

haagch commented on 2014-06-13 12:13

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

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.

Det commented on 2014-06-13 11:59

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".

haagch commented on 2014-06-13 09:37

I'm not a fan, because updates within one tag are not incremented monotonically...

Maybe so: first number is commit number, then version tag, then hash.

Det commented on 2014-06-12 21:34

Perhaps a clearer version number:

pkgver() {
cd $_name
git describe --tags --long | tr -d v | tr - .
}

1.2.0.g7422de5

klusark commented on 2014-05-08 15:57

Could you add git to your makedepends?

nariox commented on 2014-04-23 18:45

Hmm, weird, reinstalling xorg-macros solved it for me... ô.ò

All comments