FS#15895 - PKGBUILD git feature is systematically setting pkgver to today date, not date of the last commit

Attached to Project: Pacman
Opened by Hervé (herve) - Tuesday, 11 August 2009, 07:44 GMT
Last edited by Allan McRae (Allan) - Friday, 10 August 2012, 04:56 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 4.0.3
Due in Version 4.1.0
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

Details

Description:
With development packages, when you run makepkg to update the last, even if the remote git has not changed, the built package version makes you believe it was pushed just today.

On the opposite, the svn development feature is really reporting the latest changeset number.

Additional info:
* package version(s)

makepkg (pacman) 3.3.0

* config and/or log files etc.

I haven't changed makepkg.conf myself.

Steps to reproduce:

A package using _gitroot/_gitname and recompile it even if the remote hasn't changed today.
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 10 August 2012, 04:56 GMT
Reason for closing:  Implemented
Additional comments about closing:  https://projects.archlinux.org/pacman.gi t/commit/?id=024bc44a
Comment by Hervé (herve) - Tuesday, 11 August 2009, 14:35 GMT
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.
Comment by Dan McGee (toofishes) - Friday, 14 August 2009, 03:16 GMT
Patches welcome. It is tricker than it seems, I think.
Comment by Hervé (herve) - Friday, 14 August 2009, 07:47 GMT
I'll try, though I can't reassign the ticket to myself. We have done something similar for our development tools at the office.
Comment by Hervé (herve) - Saturday, 15 August 2009, 22:51 GMT
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. ;-)
Comment by Loui Chang (louipc) - Tuesday, 18 August 2009, 12:01 GMT
Hmm I wouldn't assume that master is the proper branch to check out.
Sometimes devel is done on another branch.
Comment by Hervé (herve) - Tuesday, 15 September 2009, 20:10 GMT
I updated my patch with a possible _gitbranch variable. It defaults to "master".
Comment by Hervé (herve) - Tuesday, 22 September 2009, 08:01 GMT
A better patch with checking out the required branch, and updated the documentation.
Comment by Hervé (herve) - Friday, 12 March 2010, 08:33 GMT
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.
Comment by Dan McGee (toofishes) - Friday, 12 March 2010, 13:02 GMT
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.
Comment by Gavin Bisesi (Daenyth) - Monday, 29 March 2010, 20:11 GMT
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.
Comment by Yannick LM (yannick_lm) - Thursday, 08 April 2010, 21:38 GMT
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.
Comment by Gavin Bisesi (Daenyth) - Thursday, 08 April 2010, 21:40 GMT
If you s/-/_/ on it, it seems to like it better. - is not a legal character in pkgver.
Comment by vnoel (kaouete) - Sunday, 02 May 2010, 17:22 GMT
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?
Comment by Anonymous Submitter - Wednesday, 03 November 2010, 19:19 GMT
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 ||'
Comment by Loui Chang (louipc) - Saturday, 06 November 2010, 23:10 GMT
Well that's easy to do without any special package:
git log --pretty=oneline | wc -l
Comment by dema (dema) - Sunday, 05 December 2010, 12:39 GMT
git log -n1 --pretty='format:%ct'| awk '{print strftime("%Y%m%d",$1)}'
Comment by PyroPeter (pyropeter) - Wednesday, 26 January 2011, 19:04 GMT
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.
Comment by Estêvão Valadão (estevao) - Thursday, 01 September 2011, 16:41 GMT
Why not use, for example, _gitbase/_gitrepo instead of _gitroot/_gitname?

It's working fine for me.

Loading...