OpenVibe Debian package

Come here to discuss about OpenViBE in general!
Post Reply
nbourdau
Posts: 3
Joined: Sun Jul 01, 2012 3:32 pm

OpenVibe Debian package

Post by nbourdau »

Hi everyone,

Two months ago, I started to package OpenVibe for Debian. Yann Renard was our contact back then and actually pinged me a week ago. But I had questions and since a week I have no news. So I believe the best is to post my questions on the forum. :)

So I have made an preliminary package based on the 0.13 version (I will of course update to the latest release soon). But for those interested, you can get the current source of the Debian Package in its git repository:
git://anonscm.debian.org/pkg-exppsy/openvibe.git

Now I am stucked because I need the OpenVibe project to answer few questions.


Copyright and license:

I have prepared a debian/copyright (attached) file with the information I have gathered from the latest release and from the website. Is it correct? What are the date of copyright I should specify (years of modification)? Also I doubt that everyone in the list has contributed in all files of the source code. So it could be nice to know who has contributed to what. Or maybe all the copyrights belong to the IRISA (or INRIA)... I don't know since there is no copyright header in the files. Maybe you can tell me what should be indicated here.

Moreover, I have set Laurent Bonnet as the upstream contact since he is the one noted as contact in the website. Should I use Yann Rennard contact information instead since he is currently the contact?

I indicated the LGPL-2.1 for all the files in the upstream package, am I right or are there some files that should not be under LGPL-2.1?


Separation between plugin and core:

I would like to be sure about what is meant to be plugin and what is meant to be linked directly as shared library: the "modules" part are dlopened but they are nevertheless linked altogether. On the other side the "plugin" part of the code are dlopened as expected but they depends (linked against) on libOpenViBE-dynamic.so, libOpenViBE-toolkit-dynamic.so and various modules and use directly or indirectly almost all the headers files defined by the core.

So could you indicate what should be considered as plugin, shared library or what should be integrated into the core binary. From your answer will depends how the packages will be separated. Don't hesitate to ask me to clarify my question if not clear.

Also it should be noted that if a part is build as shared library, the future releases of OpenVibe must be careful with their ABI changes: either its ABI is made backward compatible or its soname is changed.


Plugin installation:

For the moment, the plugin are installed and searched in $libdir (/usr/lib/<arch>). Once it has been decided what should be a plugin, I will write a patch to install them in $libdir/openvibe. But it would be even better this is done directly in OpenVibe source code.


VPRN:

For the moment, I have not packaged VRPN yet: it builds static libraries. So, in its current state, it might be difficult to be accepted in Debian repository. Don't worry, if it is an important dependency, I will eventually package it. But could you precise its importance for OpenVibe?


Changes worth to be considered in midterm:

The build system is quite difficult to use and quite inflexible (and slow). The reason is that it is made of lot of individual cmake projects bound together by shell scripts instead of one single and modular cmake project. For maintainability purpose of the Debian package (or in order to ease the compilation of OpenVibe by other people), it would be better if the build system could be changed into a single and modular one.

I completely understand that the OpenVibe authors have other priorities. That is why I volunteer myself to do it. But before spending too much time at doing it, I would like to know if the OpenVibe authors consider the idea interesting or you prefer to keep the build system as it is.



I am looking forward to reading your comments,
Best regards,

Nicolas Bourdaud
Attachments
copyright.txt
(1.54 KiB) Downloaded 226 times

nbourdau
Posts: 3
Joined: Sun Jul 01, 2012 3:32 pm

Re: OpenVibe Debian package

Post by nbourdau »

No one?

If you can answer/comment only on few of the point, it would be good as well.

Or maybe I don't use the correct communication channel for these questions. Should I ask by email or to the IRC channel?

Cheers,

Nicolas

jlegeny
Posts: 239
Joined: Tue Nov 02, 2010 8:51 am
Location: Mensia Technologies Paris FR
Contact:

Re: OpenVibe Debian package

Post by jlegeny »

Hello Nicolas,

since some of the answers require thorough discussion between all of the parties it might take time to answer to everything. Stay assured that we are very interested in having a proper debian package. However, as you pointed out, there is a lot of work to do.

Now for some partial answers, let me know what you think about them

Copyright and license:

All of the files in OpenViBE, except those in folders with -gpl suffix, are either licensed under LGPL-2.1 or a lesser, more permissive license (such as BSD or MIT) Most of the files are missing proper copy-left headers. Some of the code (such as the code for the fieldtrip driver) is based on dual-licensed source code files. Some drivers load proprietary DLLs. Note that these only concern Windows, for now.

Separation between plugin and core:

As a rule of thumb, openvibe, openvibe-kernel, openvibe-toolkit and openvibe-modules are members of the core. Plugins are dlopened (but depend on the modules and the toolkit)

Acquisition Server is completely monolithic in regard to the drivers, EXCEPT for the drivers which are under proprietary licenses.

Plugin installation:

The paths are coded in a way to be easily accessible on both Linux and Windows, this can be indeed separated by preprocessor clauses if necessary.

VPRN:

VRPN is a vital part of OpenViBE, as it is used for all communication with external applications. The best solution would be to have a proper debian package for it. But we are not sure about the state of the development of the library. It seems that the ftp repository has been shut down.

Changes worth to be considered in midterm:

I can not speak for all of the authors right now. But you got the idea right, the build system is far from being perfect, nevertheless it works and it is very modulable, which enables us to develop separate parts of the application easily. If you could elaborate on this solution and how to make it lighter and faster we would be thankful.

Many thanks for your interest
Jozef

nbourdau
Posts: 3
Joined: Sun Jul 01, 2012 3:32 pm

Re: OpenVibe Debian package

Post by nbourdau »

Hello!

Thanks for the reply

Copyright and license:
Ok, I will update accordingly!

Separation between plugin and core and plugin installation:
Ok, this is clearer this way: I will install openvibe, openvibe-kernel, openvibe-toolkit and openvibe-modules as binary or shared library. The only issue was that the modules were installed in the same folder as plugins. But shared libraries must be installed in /usr/lib while plugins must be in subfolder of /usr/lib. Now that I know the separation I will prepare the patch (It does not matter if if is Debian specific)

VPRN:
Ok, I've started to package it. I will see whether turning them into shared libraries break something or not.

Build system:
Ok, I will soon come up with a plan. I will put this in another post.


last point, if I submit patches (bugfix, or features), where should I submit them and against which version (release or latest svn revision)?

Cheers,

Nicolas

jlegeny
Posts: 239
Joined: Tue Nov 02, 2010 8:51 am
Location: Mensia Technologies Paris FR
Contact:

Re: OpenVibe Debian package

Post by jlegeny »

Hello,

the patches are best submitted against the latest SVN trunk. Due to the (small) size of the team we do not maintain older versions. Depending on the nature of the patch you can either submit the fix here as an attachment, by mail to me or laurent, or, if it concerns a bigger feature addition on our community forge at http://openvibe.inria.fr/community We will look for candidates for inclusion in the trunk there.

Thank you
Jozef

Post Reply