[aur-general] Revise VCS packages versioning

[Doug Newgard]

----------------------------------------
> Date: Wed, 30 Oct 2013 22:50:55 -0700
> From: anatol.pomozov at gmail.com
> To: aur-general at archlinux.org
> Subject: Re: [aur-general] Revise VCS packages versioning
>
> Hi
>
> On Wed, Oct 30, 2013 at 10:15 PM, Doug Newgard <scimmia22 at outlook.com> wrote:
>> ----------------------------------------
>>> Date: Wed, 30 Oct 2013 22:09:21 -0700
>>> From: anatol.pomozov at gmail.com
>>> To: aur-general at archlinux.org
>>> Subject: Re: [aur-general] Revise VCS packages versioning
>>>
>>> Hi
>>>
>>> On Wed, Oct 30, 2013 at 9:53 PM, Doug Newgard <scimmia22 at outlook.com> wrote:
>>>> ----------------------------------------
>>>>> Date: Wed, 30 Oct 2013 21:49:11 -0700
>>>>> From: anatol.pomozov at gmail.com
>>>>> To: aur-general at archlinux.org
>>>>> Subject: Re: [aur-general] Revise VCS packages versioning
>>>>>
>>>>> Hi
>>>>>
>>>>> On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche <adys.wh at 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
>>>>>
>>>>
>>>> Very, very bad idea. Every repo is different, the flexibility of the pkgver function lets the maintainer adapt to that. This was one of the major new features in pacman/makepkg 4.1.
>>>
>>> I do not propose to remove pkgver(). What I say is that vcs version
>>> generator becomes non-trivial and many people use different and
>>> inconsistent VCS versions. It indicates that there should be some
>>> standard way to generate version. If you don't want to use the
>>> standard generator you can use your own command to generate the
>>> version.
>>>
>>> But at least the standard generator will show how version should look
>>> like (e.g. "r" prefix or not, what delimiter should be used, etc)
>>
>> If you want the "r", add it. If not, don't. I don't see the problem.
>>
>>>
>>>> To be very blunt, if you can't figure out basic scripting enough to write a coherent pkgver function, you don't really have any> business maintaining PKGBUILDs.
>>>
>>> Please more respect, this is a public discussion.
>>
>> I'm well aware that it's a public discussion, but I'm not going to sugar coat things to protect other's feelings. Bash can be complex, but basic scripting isn't difficult. If you're going to be maintain PKGBUILDs without a grasp of the basics, you're being set up to fail from the get go.
>
> Dude, before doing these statements I suggest to look at your own
> packages. The versions of *your* packages (as well as many others) are
> inconsistent and this discussion tries to improve the situation.
>
> Anyway let's return to the original question about version generators.
> Are these "r" prefixes and the proposed "sed" good enough to make it
> standard?

Mine are inconsistent because some need it and some don't. I don't use the "r" if it can't become an issue. I still have a few that are free-form and will get the "r" added when I update the PKGBUILD in the future.

As for the sed, I would use sed -i 's/-/.r/;s/-/./g' most of the time, much easier to understand but doesn't work if the tag name has a dash.