English | Deutsch
Home »

OpenVAS Change Request #38: Reorganize OpenVAS libraries

Status: Voted +6. Done in subversion trunk (past 2.0) since 2009-09-01.

Purpose

Consolidate all libraries of the OpenVAS tool chain.

To prevent code redundancies (duplication of same code in various modules).

Simplified release management and installation.

References

This change was discussed in a session at the OpenVAS DevCon-2 in July 2009.

Rationale

A survey on libraries spread over OpenVAS toolchain shows:

Modules that will use the consolidated form of openvas-libraries would be:

From the maintenance perspective (technically as well as in terms of copyright and license), a consolidation will less trouble new developers. Clean rules on where to place API elements will provide a guide to more easily involve into the developments.

Apart from that, source code transparency is improved as well.

Effects

No effects for users, because these are internal changes.

Packagers need to adjust packaging. It does make sense to produce separate binary packages, each containing a library. That way, the clients need only to require the library packages of relevance.

In fact, this means to retire the module "openvas-libnasl". All of its contents would move into "openvas-libraries".

A side effect is that the glib minimum requirement needs to be raised to 2.12 for some of the libraries from openvas-manager.

Design and Implementation

Central idea is to collect any library in openvas-libraries module. This essentially means also to migrate libopenvasnasl into this module and to retire the module openvas-libnasl.

The new set of libraries inside openvas-libraries should be as follows:

The other libraries of openvas-manager (libomp, libotp, libmanage, libopenvas-mngr-comm and libstring) remain with that module as long as they are not required by any other module. libomp and libotp need to be renamed as they clash with openvas-libraries.

The contents of all libraries except for nasl, misc and hg are entirely new developments with clean GPL v2+ licensing.

It is still to decide whether to move towards cmake and disregard the current autotools approach for configuration of source code package. As autotools and cmake do not necessarily conflict when used in the same module, the new libraries will be managed via cmake. Eventually the whole module can get rid of the autotools.

Since there are going to be a lot of changes and the ABI might not be backwards compatible it should be ensured there is a SONAME bump when the libraries change so that people don't try to mix older versions of openvas-{client,server} with the new libraries provided by openvas-libraries.

History