Hi On Wed, Oct 30, 2013 at 10:47 PM, William Giokas <[email protected]> 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 <[email protected]> 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.
