Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#19492 - [vim,gvim,vim-runtime] version numbering

Attached to Project: Arch Linux
Opened by Ike Devolder (BlackEagle) - Monday, 17 May 2010, 07:05 GMT
Last edited by Andrea Scarpino (BaSh) - Wednesday, 02 February 2011, 07:53 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Kieslich (tobias)
Dan Griffiths (Ghost1227)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No



The version numbering of the vim and related packages needs more than just 7.2 i think

it is easier to follow upstream changes and what de difference is between the arch version and the one from

or will the version be updated in the pkgrel ?

Additional info:
* package version(s)
* config and/or log files etc.

Steps to reproduce:
This task depends upon

Closed by  Andrea Scarpino (BaSh)
Wednesday, 02 February 2011, 07:53 GMT
Reason for closing:  Fixed
Additional comments about closing:  vim 7.3.102-1
Comment by Ike Devolder (BlackEagle) - Monday, 17 May 2010, 07:16 GMT
i mean if 7.3 is out and also will last about 2 years before the next major version, then there will be a lot of pkgver's an not a real clarity which version you are really running
Comment by Jan de Groot (JGC) - Monday, 17 May 2010, 09:16 GMT
Ehm, what are you talking about? The upstream patchlevel is included in $pkgver. Upstream releases a major version and several patch packages with bugfixes.
Comment by Jan de Groot (JGC) - Monday, 17 May 2010, 10:33 GMT
hmm, outdated mirrors are fun, I see what you mean. $pkgver should contain at least some information about patchlevel or hg version.
Comment by Thomas Dziedzic (tomd123) - Monday, 17 May 2010, 14:35 GMT
I also agree that having the patch version was necessary.
Why was it removed in the first place?
Comment by Jan Alexander Steffens (heftig) - Tuesday, 18 May 2010, 22:27 GMT
The problem is that the hg revision numbers (e.g. 2150) are local (and unreliable). The global revision tags that are now used are hexstrings and would break vercmp. Not all hg revisions correspond to patchlevels. Also, if patchlevel is added back to $pkgver, it would have to be updated manually.
Comment by Ike Devolder (BlackEagle) - Tuesday, 01 June 2010, 12:01 GMT
why no longer building with the patch files ?
as in the attachement

its no big deal doing it that way
makepkg -g >> PKGBUILD
Comment by Ike Devolder (BlackEagle) - Thursday, 26 August 2010, 06:25 GMT
since vim 7.3 was released almost a week ago i present the solution i want to use,
it creates some overhead, but in my oppinion not neccesarely bad.

it creates 4 packages
vim-slim ( tiny vim, no runtime needed, for the serveradmins and so )
vim-cli ( commandline vim, all features enabled )
vim-gvim ( depending on vim-cli for the rest of the files )
vim-rt ( runtime just to have no name conflict with the official repo )

hopefully it helps, maybe good, maybe bad
Comment by Jan Alexander Steffens (heftig) - Thursday, 26 August 2010, 06:32 GMT
Bad idea to have two version of vim (vim-cli and vim-gvim) installed at the same time, since the feature sets differ for different binaries.
Comment by Tobias Kieslich (tobias) - Thursday, 26 August 2010, 17:19 GMT
Agreed, The current layout is slim and straight forward. It's also less error prone.

on the original issue, yes the patch version is basically the micro version the way we handled that before. That was one nice thing about building it from the patches, the versions were always updated./ the current version is 7.2.436 We must reflect that in our package numbers.