----------------------------------------
> Date: Wed, 30 Oct 2013 22:50:55 -0700
> From: [email protected]
> To: [email protected]
> Subject: Re: [aur-general] Revise VCS packages versioning
>
> Hi
>
> On Wed, Oct 30, 2013 at 10:15 PM, Doug Newgard <[email protected]> wrote:
>> ----------------------------------------
>>> Date: Wed, 30 Oct 2013 22:09:21 -0700
>>> From: [email protected]
>>> To: [email protected]
>>> Subject: Re: [aur-general] Revise VCS packages versioning
>>>
>>> Hi
>>>
>>> On Wed, Oct 30, 2013 at 9:53 PM, Doug Newgard <[email protected]> wrote:
>>>> ----------------------------------------
>>>>> Date: Wed, 30 Oct 2013 21:49:11 -0700
>>>>> From: [email protected]
>>>>> To: [email protected]
>>>>> Subject: Re: [aur-general] Revise VCS packages versioning
>>>>>
>>>>> 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
>>>>>
>>>>
>>>> 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.
