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