On Thu, 1 Jun 2017 09:38:01 -0400 "Walter Dnes" <waltd...@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.
pgpOuI6zD9t3e.pgp
Description: OpenPGP digital signature
