On Thu, Oct 31, 2013 at 1:43 PM, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
Hi
On Wed, Oct 30, 2013 at 10:47 PM, William Giokas <1007380@gmail.com> wrote:
On Wed, Oct 30, 2013 at 09:49:11PM -0700, Anatol Pomozov wrote:
Hi
On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche <adys.wh@gmail.com> wrote:
As someone who maintains a lot of git packages, I wish, I really wish there was a *standardized* way of writing a pkgver that would output the appropriate format whether there are tags pushed upstream or not.
That is what I intended to propose next.
As the regexp become more complicated it is better if makepkg will take care of generating the package version. I think makepkg should have a shell function, something like 'generate_pkgver_vcs()' that user can use in pkgver().
e.g.
pkgver() { cd repo generate_pkgver_vcs() }
This function will 1) Find what VCS is used 2) Generate appropriate VCS version
I would urge you to look at one of the newer features of pacman, makepkg-template. You can do such things as this very easily. I already maintain a small and probably awful repository[1]/package[2] with a few VCS pkgver functions that you can use. Mostly they have been taken from the wiki, though I do have a nice, long sed expression that does the 'r' prefixing (I wrote that talk article).
[1]: http://git.kaictl.net/wgiokas/makepkg-templates.git/ [2]: https://aur.archlinux.org/packages/makepkg-templates-ks-git/
--SNIP--
Another issue is a repo that has no tags. Here is a recommendation from the wiki page:
printf "%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
that will use number of commits (a large number e.g. 3000). The problem arises when the project creates first tag e.g. 0.1. I suggest to fix this problem by using "0" as a tag version (and add prefix 'r' like in the previous item). This makes sure that non-tagged version is always less that a tagged version.
So pkgver() will look like:
printf "0.r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
Let me know if you have any objections. If not then I'll update the wiki page.
This is not needed at all. If the project starts using tags, use an epoch= to set all versions from then on to be greater than the original versions with rev-list.
Personally I do not like using epoch for such cases as it uglifies the version number.
I see 2 options for non-tagged versions:
1) With "0." prefix. e.g. "0.r453". So beginning of the project history acts as a "release number zero" that is lower than any tagged version.
2) Without the prefix. e.g. "r453", it also works fine and makes the version a little bit shorter.
$ vercmp 0.1 r543 1
I prefer option #1 as it makes version more consistent between tagged and non-tagged versions, but I can live with #2 as well.
BTW Most of the -git packages add 'short SHA1 of the HEAD' as suffix e.g. '2.2.r9.g6c8d8ae-1'. In fact this SHA1 (g6c8d8ae in this example) is not used in the version comparison and not needed. I suggest to drop the SHA1 from recommended -git version and leave only the 'rXXX' part, e.g.
0.r32.gfoobar => 0.r31 2.2.r4.g23423234 => 2.2.r4
This makes versions shorter and nicer, and makes it more consistent with other VCS.
The sha1 is useful to people who need to quickly tell developers which version they are running when they're from git. Removing it is a bad idea. The main issue with -git versioning is the inconsistency. The proto file for it is terribly out of date, not everyone respects whatever flavour of the recommended way is current, and not every git repository has tags (creating a need for two different functions, the need of which cannot be told until build time). A further issue arises from that, which is that repositories without tags may get tags later on and the package maintainer may not know about that (leaving the old versioning in), or using the new versioning may break versioning for other packages. I'm not suggesting we drop the pkgver function (nobody is). I'm saying we need a standardized pkgver script that outputs consistent, compatible results between tagged and non-tagged git repos, and recommend that as the proto. To that end, I liked the proposal of 0.7.r19.ge4e6e20 vs 0.r19.ge4e6e20. J. Leclanche