On Thu, 1 Jun 2017 09:38:01 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

>   As mentioned elsewhere, what happens when two or three other people
> do their own forks?  Plugin 1 works with vim A and B but not C or D.
> Plugin 2 works with vim A and C and D but not B.  The number of
> directories could potentially be 2^N where N is the number of forks.
> And who's going to do the necessary testing across multiple versions?
> And remember that each minor version bump of any of the forks could
> render another fork's plugin incompatable.  This is a classic "moving
> target".  The only way that works is to have each fork look after their
> own copies of plugins.

If and when that happens:

1. Packages that are available on only one vim still install to the one dir
2. Packages that are available on >1 install to a common dir
3. Vim runtimes *don't* all use the common dir, but only their own
4. Packages that support multiple vims get symlinked into their respective
   vim paths at install time.

"4" could be done in a PYTHON_TARGETS sort of way, but its obvious to see why
I'd say "lets not do that unless we absolutely have to".

"4" could alternatively be implemented by creating a meta-file that enumerates
a list of source files to symlink, and the list of vim implementations that are
known to be supported by it, and then a tool can fix up the difference in pkg_postinst
or on-demand.