Arch Linux

For the record, I was trying with the "pyflakes_ast-git" package from AUR. The git mirror mirror hasn't been updated in 4 months.

Patches welcome. It is tricker than it seems, I think.

I'll try, though I can't reassign the ticket to myself. We have done something similar for our development tools at the office.

Here is my proposal.

The difficulty was to convert a timestamp to a date using only bash. I think only GNU date knows the "@epoch" syntax. I could have used awk too but I don't think it is available as a dependency. The double "cut" is because I don't know how to say "the last but one field", similar to awk's "$(NF-1)".

The timezone is ignored but it's not that important. Here the date is just a reference point to compare versions of a package.

Probably some git expert will find a better command or make git output the date directly in "%Y%m%d" format.

Nice that pacman is itself versionned using git. ;-)

Hmm I wouldn't assume that master is the proper branch to check out.
Sometimes devel is done on another branch.

I updated my patch with a possible _gitbranch variable. It defaults to "master".

A better patch with checking out the required branch, and updated the documentation.

I've updated my patch. No worry about TZ, date doesn't apply it anyway:

$ date -d "2010-02-18 23:44:20 +0100" +"%Y%m%d"
20100218

or it would give "20100219"

It could be applied now, before any VCS refactoring, I've already waited for 6 months. And it's not related to any SVN issue.

The idea behind the VCS refactoring is that we introduce less of this code into core makepkg, not more. Having VCS commands hardcoded is less than ideal, especially when the problem hasn't been solved for the others yet so we may not know what a more general solution is.

There is nothing preventing you from running with this patched makepkg, and we do appreciate the work, but it needs more thought on a grander scale before we go off half-cocked and implement this in makepkg for all possible VCSes.

Would it make sense to use "git describe" to generate the pkgver? It's a "real" pkgver, but I'm not sure that it will always generate incrementing versions unless the repo has version tags.

Yeah but for instance

1.5

1.5-2-gfea85c

are the same for vercmp ...


> but I'm not sure that it will always generate incrementing versions unless the repo has version tags.

if there's not tag , git describe --always return a short SHA1.

If you s/-/_/ on it, it seems to like it better. - is not a legal character in pkgver.

Would like to make a comment:

What happens if I just want to use git to get a release (by tags for example): I wouldn't want the pkgver to be changed!

Can it be possible to have both behaviours?

Maybe you can use git-count (from git-extras package) to count the actual number of commits similar to rev num in svn or bzr, for pkgver instead of using the date.

git-count | sed 's|total ||'

Well that's easy to do without any special package:
git log --pretty=oneline | wc -l

git log -n1 --pretty='format:%ct'| awk '{print strftime("%Y%m%d",$1)}'

Without having read the discussion in depth the only sensible way of handling git versions would be to set pkgver to something derived from git-describe.
As not all projects use tags (and there is the branch issue louipc has mentioned), I would not change the default behavior, but add this as a new option, e.g. "git-tagver".

On the format of the derived pkgver:
Most projects name their tags after their releases, so it would make sense to take the version of the last release and add the number of changes:
1.5-2-gshjkdfg86 => 1.5.2


On more general matter:
When I wrote my first git-PKGBUILD I was very surprised by the inconsistent way makepkg handles svn/git/csv-packages:
On the one hand it automatically sets $pkgver to something unsensible (except for svn packages). On the other hand it does not automatically clone the repository. It also relies on variables starting with an underscore.

Imho it would be sensible to either add real support (clone,pull,$pkgver) for version control systems to makepkg or remove the support completely.
There is no need for svn/git/cvs-support: One could manually set $pkgver in build() after cloning the repo. (Maybe this is impossible because of design decisions?) This would also be a solution to the branch issue.

Why not use, for example, _gitbase/_gitrepo instead of _gitroot/_gitname?

It's working fine for me.