[arch-dev-public] About the vim packages (Opinions needed)
Hi @all, as most of you know, the (g)vi* packages are a constant subject to suggestions and proposed changes be they stupid or valid. I just like to have some input on two major issues and if we shall pursue them or not: Only vim and gvim are concerne since vi is an entirely different beast now. Here is how the packages are split up: vim: - perl scripting support, since it's small and produces minor overhead - provides runtime files - is mainly intended for command line use where vi is not sufficient gvim: - python (and later again ruby) scripting support for addon scripts - provides X support, vim server support, gtk frontend if invoked with gvim symlink - intended for serious development, I think it's a reasonable assumption that people who do that do not wanna have 80x24 consoles but will have X installed and with X there is a huge likely hood that gtk2 is installed Now, I think that gives a nice and very clear distinction between vim (mainly for console user) and gvim (for developers, but also people who run the vim command in the terminal). Note that after installing the gvim package, the vim command invokes a more powerful, python and X enabled binary. I am getting feature requests, to put it nicely, about enabling python in vim. I'm opposed to that for two reasons: - upon the return of ruby people will pester me about ruby support becuase python is in there and why not ruby .. whine .. blah - I think there is a clear distinction between vim for the console and vim for serious development, and the current layout shows that nicely The arguments about including python are mainly like that: But when I am on this server, or on this very small box, too small to run X and I wanna develop in python etc. I don't think these are valid arguments because they are rare cases. And if it's really true, you can always build a custom python enable smaller vim. Which brings me directly to the second point, the building system. Vim follows a patch based approach which makes the PKGBUILD a fair bit complex. All thes seemed to be fine for the last year but now people seriously pester me that it would be better to build it from cvs/svn and the patch based approach is not good enough anymore because the rebuilds take too long becuase the download takes soooo long. The cvs approach however has a few gotchas IMHO: - first of all I think that's a non issue, becuase Arch is binary based and rebuilding is not really necessary - cvs/svn is behind the patches in vim world - if you rebuild, you rebuild more often, which is supported by the central srccache - I clean up my PKGBUILD directories before rebuilding, I never clean my SRCCACHE so overall I don't benefit from the cvs at all So what I wanna know is, 1. Do we wann have python enabled in vim package (don't forget: as soon as you install the gvim package, you have python in vim and don't use the vim-package binary anymore) 2. Do we wanna have a cvs enabled buildsystem just because upon an initial rebuild the download is faster (It would annoy the hell out of me because as package maintainer I would have to dowload everything everytime) So, I like (g)vim the way it is but I don't wanna be the benevolent I would be okay with 1) if everyone agrees, I know quite few developer use vim. I'm strongly opposed to 2) because it just causes more work and we do have a perfectly usable build system in place. -T
On Sun, Oct 11, 2009 at 10:45 PM, Tobias Kieslich <tobias@justdreams.de> wrote:
Which brings me directly to the second point, the building system. Vim follows a patch based approach which makes the PKGBUILD a fair bit complex. All thes seemed to be fine for the last year but now people seriously pester me that it would be better to build it from cvs/svn and the patch based approach is not good enough anymore because the rebuilds take too long becuase the download takes soooo long. The cvs approach however has a few gotchas IMHO: - first of all I think that's a non issue, because Arch is binary based and rebuilding is not really necessary
I don't rebuild that much. But the fact that rebuilding is so nice and so simple in Arch is one of my main reasons for preferring it over other distrib.
- cvs/svn is behind the patches in vim world
The lag between two vim packages bump is likely to be much bigger, so I am not sure that is really relevant. But vim development model must be the weirdest one I have seen so far :)
- if you rebuild, you rebuild more often, which is supported by the central srccache - I clean up my PKGBUILD directories before rebuilding, I never clean my SRCCACHE so overall I don't benefit from the cvs at all
Not that it matters at all, but I find it funny that I do the opposite. I don't use a central src cache but I always keep my build directories. Anyway, I don't think we were not talking about a -cvs package like the ones on AUR. What aaron suggested is a libfetch like way, that is you just generate a snapshot, and upload it to ftp.archlinux.org. http://repos.archlinux.org/viewvc.cgi/libfetch/trunk/PKGBUILD?revision=49959&view=markup Surely there are other official packages using cvs/whatever snapshots.
I'm strongly opposed to 2) because it just causes more work and we do have a perfectly usable build system in place.
What bugged me is the very unusual way the vim pkgbuild used to get source code. And that it used two long and complex patches to do that : $ wc -l fetch_* 67 fetch_patches.sh 117 fetch_runtime.sh 184 total So we have a big script to download and apply hundred of patches inside the build() function. And we have an even bigger script to download and replace runtime files inside the package() function (if there was one), directly overwriting the files in $pkgdir/ This is not really your fault however, this is all due to the crappy (or if you prefer : very unusual) vim development model, as I have found out in the last two weeks. But I also found out there is an alternative to that, which I proposed. Anyway, it's your package, you are the maintainer. If you see only inconvenient and no advantages with my alternative, forget it. For a user who wants to build/rebuild vim regularly, I think it would be nicer to use a real -cvs or -git pkgbuild as the ones I submitted to the AUR. And I would also like to mention I had no problems with vim before looking at the pkgbuild, the packages have always worked fine. And I also appreciated the recent cleanup/reorganization (my only complaint was the lack of information in the announcement). So your work is appreciated.
Tobias Kieslich wrote:
2. Do we wanna have a cvs enabled buildsystem just because upon an initial rebuild the download is faster (It would annoy the hell out of me because as package maintainer I would have to dowload everything everytime)
Can we not just do something like the bash PKGBUILD? if [ $_patchlevel -gt 000 ]; then for p in $(seq -w 001 $_patchlevel); do source=(${source[@]} http://ftp.gnu.org/gnu/bash/bash-4.0-patches/bash40-$p) done fi
On Sun, Oct 11, 2009 at 5:46 PM, Allan McRae <allan@archlinux.org> wrote:
Tobias Kieslich wrote:
2. Do we wanna have a cvs enabled buildsystem just because upon an initial rebuild the download is faster (It would annoy the hell out of me because as package maintainer I would have to dowload everything everytime)
Can we not just do something like the bash PKGBUILD?
if [ $_patchlevel -gt 000 ]; then for p in $(seq -w 001 $_patchlevel); do source=(${source[@]} http://ftp.gnu.org/gnu/bash/bash-4.0-patches/bash40-$p) done fi
Yes and no. After it hits 100, they make one big bundle for those 100 patches and remove the originals (it's stupid). So if the patch level is 342, you need to download patches "1-100", "101-200", "201-300", 301, 302, ..., 341, 342.
On Sun, Oct 11, 2009 at 3:45 PM, Tobias Kieslich <tobias@justdreams.de> wrote:
Now, I think that gives a nice and very clear distinction between vim (mainly for console user) and gvim (for developers, but also people who run the vim command in the terminal). Note that after installing the gvim package, the vim command invokes a more powerful, python and X enabled binary.
I am getting feature requests, to put it nicely, about enabling python in vim. I'm opposed to that for two reasons: - upon the return of ruby people will pester me about ruby support becuase python is in there and why not ruby .. whine .. blah - I think there is a clear distinction between vim for the console and vim for serious development, and the current layout shows that nicely
The arguments about including python are mainly like that: But when I am on this server, or on this very small box, too small to run X and I wanna develop in python etc. I don't think these are valid arguments because they are rare cases. And if it's really true, you can always build a custom python enable smaller vim.
It's a bit bold to state that gvim is for "serious developers". I use vim at home and at work for day to day development, and use gvim approximately 10% of the time (when I need to do something on a Windows VM, because cmd.exe sucks). On a Linux machine, I don't think I've actually started gvim in like 3 years.
- first of all I think that's a non issue, becuase Arch is binary based and rebuilding is not really necessary
This relates directly to the above. Yes, Arch is binary based, but if vim isn't compiled with +python support, I know I am going to rebuild it. If people give lots of feature requests that are denied, they will simply rebuild it from ABS. That's what we do. The proposal Xavier had was to expedite that process. I don't really care HOW it's accomplished, but he's correct that having these crazy scripts to download stuff is overkill. There's a middle-ground, however. We can do the download once, make a tarball of it, and stick it in ftp/other/ for ABS users to rebuild from. I believe this was proposed in a PKGBUILD Xavier emails around (a _mksrc function similar to libfetch). It doesn't have to use CVS, but if we provide a tarball somewhere and simply base the PKGBUILD off that, instead of doing complex bash gymnastics, we meet in the middle here. The gist of this is, if you're denying these feature requests (which is totally fine), then expect people to be rebuilding a lot. If this happens, then the PKGBUILD probably needs to be a tad plainer / quicker
On Mon, Oct 12, 2009 at 9:15 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
It's a bit bold to state that gvim is for "serious developers". I use vim at home and at work for day to day development, and use gvim approximately 10% of the time (when I need to do something on a Windows VM, because cmd.exe sucks). On a Linux machine, I don't think I've actually started gvim in like 3 years.
vim is the only editor I use, for development and for everything else. And I actually didn't even have gvim installed. I don't need gvim, I don't need X support, I might need python support but usually I don't. If it was up to me, I would enable python support, but I realize it's difficult to make everyone happy so I don't care much.
There's a middle-ground, however. We can do the download once, make a tarball of it, and stick it in ftp/other/ for ABS users to rebuild from. I believe this was proposed in a PKGBUILD Xavier emails around (a _mksrc function similar to libfetch). It doesn't have to use CVS, but if we provide a tarball somewhere and simply base the PKGBUILD off that, instead of doing complex bash gymnastics, we meet in the middle here.
I included the PKGBUILD for reference. If we use tarball + patches, I am not sure whether we should use a _mksrc function or try to go with the bash-package way. In the latter case, we need to support the patch bundles. afaik the original patches remain on ftp, but downloading 260 patches is slow. Downloading 62 patches is better. So it would be more complex than bash pkgbuild, but probably doable. I can look into it.
On Mon, 12 Oct 2009, Xavier wrote:
On Mon, Oct 12, 2009 at 9:15 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
It's a bit bold to state that gvim is for "serious developers". I use vim at home and at work for day to day development, and use gvim approximately 10% of the time (when I need to do something on a Windows VM, because cmd.exe sucks). On a Linux machine, I don't think I've actually started gvim in like 3 years.
vim is the only editor I use, for development and for everything else. And I actually didn't even have gvim installed. I don't need gvim, I don't need X support, I might need python support but usually I don't. If it was up to me, I would enable python support, but I realize it's difficult to make everyone happy so I don't care much. The issue here is that the problem is about semantics as well. Installing gvim does not mean you have to fire it up. But just by installing it you get a vim binary that has python support. That is because of the way vim handles it behaviour based on binary names that is achieved by symlinking. And it is intended this way.
There's a middle-ground, however. We can do the download once, make a tarball of it, and stick it in ftp/other/ for ABS users to rebuild from. I believe this was proposed in a PKGBUILD Xavier emails around (a _mksrc function similar to libfetch). It doesn't have to use CVS, but if we provide a tarball somewhere and simply base the PKGBUILD off that, instead of doing complex bash gymnastics, we meet in the middle here.
I included the PKGBUILD for reference.
If we use tarball + patches, I am not sure whether we should use a _mksrc function or try to go with the bash-package way. In the latter case, we need to support the patch bundles. afaik the original patches remain on ftp, but downloading 260 patches is slow. Downloading 62 patches is better. So it would be more complex than bash pkgbuild, but probably doable. I can look into it.
What we used to have is an accumulated patch. Everytime the package was rebuilt, the missing patches got downloaded and attached to the accumulated patch which was controlled in cvs at the time with the PKGBUILD file. The advantage of doing that is, cvs took care of the difference, abs(rsync) downloads only the difference, and it was relatively easy to maintain. Certainly easier than compiling a tarball for every rebuilt and uplaoding it to ftp. Downside is we would store a lot of stuff in the repository. The whole purpose of doing it the other way is to save the download from our servers, have NOTHING else to do but build and uplaod the package for a rebuilt and store already downloaded stuff locally so people don't have to download all patches, all of the time. It's more complex to write initially but from a maintainers point of view it's fire and forget. Incorporating to download the gzipped 1-x00 patches should be done because it cuts down on the download time and bandwith. Arguably, the cvs based PKGBUILD would be just as easy except for the fact that tyhe source trees must be copied to assure that they are clean and who knows how vims csv runtime compares to the stuff you download with rsync or their internal aap tool(which we mock in bash). -T
On Mon, Oct 12, 2009 at 10:07 PM, Tobias Kieslich <tobias@justdreams.de> wrote:
What we used to have is an accumulated patch. Everytime the package was rebuilt, the missing patches got downloaded and attached to the accumulated patch which was controlled in cvs at the time with the PKGBUILD file. The advantage of doing that is, cvs took care of the difference, abs(rsync) downloads only the difference, and it was relatively easy to maintain. Certainly easier than compiling a tarball for every rebuilt and uplaoding it to ftp. Downside is we would store a lot of stuff in the repository. The whole purpose of doing it the other way is to save the download from our servers, have NOTHING else to do but build and uplaod the package for a rebuilt and store already downloaded stuff locally so people don't have to download all patches, all of the time. It's more complex to write initially but from a maintainers point of view it's fire and forget. Incorporating to download the gzipped 1-x00 patches should be done because it cuts down on the download time and bandwith. Arguably, the cvs based PKGBUILD would be just as easy except for the fact that tyhe source trees must be copied to assure that they are clean and who knows how vims csv runtime compares to the stuff you download with rsync or their internal aap tool(which we mock in bash).
An accumulated patch might be better. But still not as good as a vcs in my opinion. The way I see it, storing and providing patches in a nice way is the whole point of vcs. If you are completely opposed to building snapshots and using a pure -cvs package (like the one here : http://aur.archlinux.org/packages/vim-cvs/vim-cvs/PKGBUILD), I am not sure what remains. Probably doing it the bash-pkgbuild way. I re-used Ranguvar code (http://bugs.archlinux.org/task/16165?getfile=4082) to do it. See attached pkgbuild. It's quite ugly if you ask me, it's still very slow to download all the patches the first time. And it looks weird to have 100 source files and 100 md5sums in a pkgbuild. Besides makepkg also takes some times to md5sum check all these and apply the patches. But at least it follows the right way to use remote source files in a PKGBUILD, by using the source array.
participants (4)
-
Aaron Griffin
-
Allan McRae
-
Tobias Kieslich
-
Xavier