| 1 |
On Thu, 1 Jun 2017 09:38:01 -0400 |
| 2 |
"Walter Dnes" <waltdnes@××××××××.org> wrote: |
| 3 |
|
| 4 |
> As mentioned elsewhere, what happens when two or three other people |
| 5 |
> do their own forks? Plugin 1 works with vim A and B but not C or D. |
| 6 |
> Plugin 2 works with vim A and C and D but not B. The number of |
| 7 |
> directories could potentially be 2^N where N is the number of forks. |
| 8 |
> And who's going to do the necessary testing across multiple versions? |
| 9 |
> And remember that each minor version bump of any of the forks could |
| 10 |
> render another fork's plugin incompatable. This is a classic "moving |
| 11 |
> target". The only way that works is to have each fork look after their |
| 12 |
> own copies of plugins. |
| 13 |
|
| 14 |
If and when that happens: |
| 15 |
|
| 16 |
1. Packages that are available on only one vim still install to the one dir |
| 17 |
2. Packages that are available on >1 install to a common dir |
| 18 |
3. Vim runtimes *don't* all use the common dir, but only their own |
| 19 |
4. Packages that support multiple vims get symlinked into their respective |
| 20 |
vim paths at install time. |
| 21 |
|
| 22 |
"4" could be done in a PYTHON_TARGETS sort of way, but its obvious to see why |
| 23 |
I'd say "lets not do that unless we absolutely have to". |
| 24 |
|
| 25 |
"4" could alternatively be implemented by creating a meta-file that enumerates |
| 26 |
a list of source files to symlink, and the list of vim implementations that are |
| 27 |
known to be supported by it, and then a tool can fix up the difference in pkg_postinst |
| 28 |
or on-demand. |
Archives