[arch-dev-public] About the vim packages (Opinions needed)

[Tobias Kieslich]

On Mon, 12 Oct 2009, Xavier wrote:

> On Mon, Oct 12, 2009 at 9:15 PM, Aaron Griffin <aaronmgriffin at 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