![](https://seccdn.libravatar.org/avatar/25bbc96d9c53647354cb724e744b2222.jpg?s=120&d=mm&r=g)
On Sat, Dec 5, 2015 at 7:28 AM, Ronan Arraes Jardim Chagas <ronisbr@gmail.com> wrote:
Hi guys!
I'm trying to submit neovim to openSUSE:Factory. There were other users that created a package for it but AFAIK have never submitted to the official devel repos.
The problem is that there were many packages needed to build neovim that are not in Factory yet. The list is:
_ libunibilium; _ lua51-BitOp; _ lua51-LPeg; _ lua51-MessagePack; _ msgpack 1.3.0; _ python-click 6.2; _ vterm.
The status right now is:
* lua51-BitOp, lua51-LPeg, and lua51-MessagePack was already accepted in the devel repo devel:languages:lua and they are ready to be submitted to factory.
* msgpack 1.3.0 was already accepted in devel:libraries:c_c++ and it is also ready to be submitted to factory.
* python-click 6.2 was already accepted in devel:languages:python and it is also ready to be submitted to factory.
* libunibilium, as per ismail advice, will be submitted to devel:libraries:c_c++.
Thus, my only problem is with vterm. I'm not sure to which devel repo I should submit it. It is not "just" a lib, because it contains three executable files inside it. When I called this package libvterm, rpmlint complained about it.
Once all these packages are accepted in Factory, I will submit neovim to editors devel repo.
Regards, Ronan Arraes
It looks like vterm is a specific add on to vim: http://www.vim.org/scripts/script.php?script_id=4546 If so, I'd put it in the editors devel repo where neovim will live. c_c++ is more of a catchall when you can't think of a better place to put something. In general, it is best to have dedicated dependencies like vterm in the same dev repo as the consumer of the api in my experience. As to the package name, libvterm is a perfectly good package name if a majority of the functionality is the library. If there are a few executables that are provided as utilities, just put them in a sub-package. I do that with libpff as an example: https://build.opensuse.org/package/show/security:forensics/libpff note, in the case of libpff, upstream calls the exe sub-package "libpff-tools", so I follow that lead and simply ignore the warning from rpmlint that I have a tools package starting with lib in the name. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org