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
Opened by Hervé (herve) - Tuesday, 11 August 2009, 07:44 GMT
Last edited by Allan McRae (Allan) - Friday, 10 August 2012, 04:56 GMT
|
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
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
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. ;-)
Sometimes devel is done on another branch.
$ 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.
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.
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.
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?
git-count | sed 's|total ||'
git log --pretty=oneline | wc -l
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.
It's working fine for me.