Using Vim's native packages feature in Debian packages

[James McCoy]

Hi Sam!

Thanks for the investigation and report.

On Tue, Dec 13, 2016 at 01:16:13PM +0000, Sam Morris wrote:
> I experimented with modifying a package I maintain to use Vim 8's new
> packages feature instead of vim-addon-manager.

I've been intending[0] to adapt vim-addon-manager to support the package
feature, as well, since that would help address various shortcomings[1] in
v-a-m's behavior currently.

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827627#18
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438482

> I encountered no serious
> problems, and made the following observations:
> 
>    1. A (Debian) package can drop files in
>       /usr/share/vim/vim80/pack/${debpkg}/{start,opt}/${vimaddon}

I'm not keen on installing under the vimXY directory, as that's Vim's
territory, and requires migration when there are new major releases.

In my current proposal, the layout would be
/usr/share/vim/packages/pack/dist-bundle/start/${debpkg} (for simple
addons) and /usr/share/vim/packages/pack/${debpkg}/{start,opt}/... (for
actual packages, which I have yet to see in the wild).

I have yet to square this with supporting Neovim, though, since there will
be addons that work for both Vim and Neovim, as well as some that are
exclusive to one or the other.

An alternative would be for addons to install under
/usr/{share,lib}/${debpkg} (which vim-command-t currently does), and
then have a vim-addon-manager trigger to handle reading the registry and
symlinking things into a common location.  That would also address the
maintainer scripts issue.

>    2. If 'start' is used, the vim addon will be loaded automatically (as
>       is already done by several Debian packages)

I'm slowly coming around to this being a reasonable default.  I've been
hoping (for years) that we would be able to support overriding a
system-enabled addon while using a user's addon, but that hasn't
happened.  I need to stop dragging my feet just because that isn't
solved.

>    3. If 'opt' is used then the user has to put 'packadd ${vimaddon}' in
>       their .vimrc; this is more like how vim-addon-manager is supposed to
>       be used, with users opting in to installed Vim addons
>    4. I was not sure how best to depend on Vim 8 or higher. I settled on
>       'Depends: vim-common (>= 2:8)'

That works.  It's requiring a bit newer version than is necessary, but
that's probably irrelevant.

>    5. I had to build-depend on vim-common, and invoke helpztags in my
>       install rule in order to generate help tags

Yeah, ideally that would be handled automatically instead of requiring
every maintainer to implement that.

>    6. Lintian wasn't happy that I shipped a shared library under
>       /usr/share

>     Dropping the maintainer scripts felt good! :)
> 
>     If it was decided to deprecate the use of vim-addon-manager in favour
>     of Vim's native packages feature, /usr/{share,lib}/vim/packages could
>     be added to packpath,     and Debian packages could ship their addons
>     inside these directories, under pack/${debpkg}/{start,opt} (depending
>     on whether the addons should be enabled automatically or not).

Hmm, interesting idea.  I think to help with the vim/neovim issue, it
would still be useful to publish something like v-a-m's
registry/${addon}.yaml, but referring to a set of directories rather
than files.  Vim and Neovim could have triggers for the registry files
and then setup the symlinks based on which editors the yaml file
declares compatibile.

Any feedback or suggestions gladly welcome.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB