[aur-general] Revise VCS packages versioning

Anatol Pomozov anatol.pomozov at gmail.com
Thu Oct 31 01:09:21 EDT 2013


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)

>  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.


More information about the aur-general mailing list