[aur-general] Revise VCS packages versioning

Doug Newgard scimmia22 at outlook.com
Thu Oct 31 01:41:01 EDT 2013


----------------------------------------
> Date: Thu, 31 Oct 2013 01:32:03 -0400
> From: ido at kernel.org
> To: aur-general at archlinux.org
> Subject: Re: [aur-general] Revise VCS packages versioning
>
> Anatol, Doug,
>
>
>>> 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.
>>
>
>
> My reading of Anatol's post does not convey any lack of understanding of
> the basics of shell scriptings. I think you are misreading his original
> post, and responding ad hominem as a result of that misunderstanding.

I can see where my comments may have come off that way, but I wasn't trying to accuse Anatol of not understanding shell scripting. My position is simply that adding a complex regex to makepkg that tries to cover as many uses as possible is folly when it could and should be done by the maintainer of the PKGBUILD where it can be targeted to the repo being used and therefor MUCH simpler. 		 	   		  


More information about the aur-general mailing list