Arch Linux

Note: Changing the _patchlevel variable changes the pkgver variable[1] which in turn changes the dependency (on vi)[1] to point to a non-existing package. To make the PKGBUILD work in its current state, _patchlevel and pkgver need to be modified.

[1] pkgver=${_srcver}.${_patchlevel}
[2] depends=("vi>=${pkgver}" 'perl' 'python' 'acl')

Archlinux is mainly a binary distribution and our PKGBUILDs cater toward that. In vim's case that catch is in there, that when the package gets build we do build the latest version. Also on top of that, if someone rebuilds vim I can foresee more reasons to build the latest version then I can see to rebuild th version we have in the repositories anyway. So all a rebuilder has to do is to replace patch number and s/he should be fine. Yes that means you should rebuild vim and gvim too, but that makes sense anyway because all three are so strongly interdependent.

I would prefer to get the patchlevel defined in the PKGBUILD and just building that, instead of bailing out when upstream has more patches.
If upstream adds a patch in the time you're building gvim and vim, you'll have to redo the whole package. This is also true when someone else needs to do an architecture rebuild for x86_64 for example.

I very much like the current approach. Although in the past when i tried to build vi and family it seemed confusing.I think too much work was put up to get this working the way it does and i will be a waste if this changes. There is no perfect way to deal with this and part of it is upstreams fault. -1

There ought to be an official ABS philosophy that describes what the goal of the ABS is.
Is ABS supposed to provide a simple, always working, mechanism for compiling packages on your own?
Or is the aim of the ABS to allow people to build the latest package, without as much emphasis on it always being straightforward and always working?

[1] should be ftp://ftp.vim.org/pub/vim/patches/7.2/MD5SUMS

The philosophy behind ABS is that what is in ABS matches the binary packages available in the repositories. At this moment we're breaking that rule with vim.

I agree with Jan here. The fetch_patches script should probably just download patches *up to* the _patchlevel variable.

The PKGBUILD should be able to build the same package as one sees in the repos.

Theres is more trouble ahead

ftp://ftp.vim.org/pub/vim/patches/MD5SUMS
provides:
An error occurred while loading ftp://ftp.vim.org/pub/vim/patches/MD5SUMS:
Could not connect to host ftp.vim.org.

which leads to :

http://ftp.vim.org giving:

ftp.vim.org has been registered for future usage.

Couldn't find a mirror that worked

Ping tobias

hm when vim dows not provide the patches anymore we are screwed anyway. because they are located in the same directory where the MD5SUMS file is located.
My guess their ftp server is down. Nothing wrong with our PKGBUILD files on that part.

I imagine that that is an upstream issue that ought to resolve itself.
I visited #vim on FreeNode and it seems it might be a DNS record or something.
Try 192.87.102.43 and 192.87.102.42

@tobias: What about the previous points that Jan and I mentioned, regarding being able to rebuild the exact same package via the PKGBUILD in abs

Aaron,

the wole build thing is madness and extremely hackish in order to force vim's source structure into our PKGBUILD way. I have this check in there to make sure that we always build the absolutely latest version of vim. in Theory there shall never be a reason to build older versions, because any new version is pretty much a bug fix. I agree with Jan that in theory it breaks ABS, yet for me it was always the most practical way as it allows me to make sure I'm uptodate and I can find out the most recent version number just from the scripts output. If it makes people happy I can remove it, it's just a tad more work for me to build it then. Either way I'm not religious about it.

What if you have it just output a warning saying "Building version X, current version is Y"?

Building the latest wouldn't be so bad if the buildscript actually computed the patchlevel based on the number of patches rather than dieing when the hardcoded patchlevel didn't match the dynamic number of patches available. Though if the philosophy of ABS is to provide the ability to build what is in the repository, Aaron's approach sounds nice.

that would be an approach that the svn packages are doing, that should be possible. Thoughts? I'm fine with Aarons solution as well

This breaks fetch_patches.sh

ba91b19374cee90f71b8f4ab1d92dc0f 7.2.001-100.gz

looks like they added a compressed patch to the list and fetch_patches can not process it

adding this
sed -i '/7.2.001-100.gz/d' MD5SUMS
to fetch_patches.sh will let it build but you will miss that patch

great, they did it again and broke the scheme of the patch naming. It's kind of a pain in the neck ...

Actually, vim has don't that since the 6.X releases - when the patch level hits 100, it becomes one giant patch. It's a little annoying for automation

Why don't you save the MD5SUMS file locally and include it in the PKGBUILD sources?
That way the PKGBUILD always stays consistent with the package. And it is very easy to update, just get the new MD5SUMS file.
Maybe the patchlevel variable could then be dropped.

As for that .gz patch, it should be easy to support. It might be even possible to do something funny like this :
(zcat $patch 2>/dev/null || cat $patch) | patch -p1 :)

Little patch that fixes the script and should work http://flo.server-speed.net/stuff/private/fetch_patches.sh.diff
You can now build the package with any patchlevel you want to.

Another little patch for fetch_patches.sh.

This one uses patch collections mentioned in MD5SUMS as .gz to speed up download of the patches.

The issue is taken care of in testing an d hopefully will be deployed to extra soon