2011/12/5 Fr?d?ric Boh? <fredericbohe at
eaton.com>:> Hello,
>
> I am currently working on getting rid of libraries dependencies from
> nut-scanner. Currently nut-scanner depends on several external libs
> (avahi, snmp, neon, usb). This becomes a nightmare in terms of
> distribution.
> So Arnaud asked me to dynamically link those libraries so we come back
> to a viable package.
right, the idea is to uncouple compile time for distribution / runtime.
Ie, when packaging, we will want to maximize features. These are then
splitted into various packages, to lower dependencies pulling.
As an example with Debian, there is nut-server (serial / USB drivers +
upsd => deps on libusb), then nut-xml (libneon), nut-snmp (Net SNMP),
and nut-ipmi (FreeIPMI, scheduled), ...
nut-scanner would on its side need a dedicated package, that would
pull all these deps, whatever the exacts need are (Ie, only USB and
SNMP).
The idea is now to dlopen on our own, instead of being linked hard to the libs.
This allows the end user to have the liberty to install only what he
needs for discovery.
This means that nut-scanner could be part of the core package
(nut-server or nut-client), and we would leave up to the users to
install what he wants.
> To do this, I ended up choosing libltdl for a portable implementation
> but I have never used it before. So if any reader has feed back on this
> lib, he is welcome to share it with us.
>
> Using this external library raise another issue : it's another
> dependency ! To solve this, the libltdl project suggest to incorporate
> the libltdl sources to the project and compile it with the rest of the
> sources. At first glance it should be a 100ko~150ko addition of code,
> which is rather big, but it is for the sake of portability.
that's the issue: to do this, we need to have a portable dlopen, that
work on all our OS scope.
Which is what is done by libltdl (portable dlopen() from the Libtool project)
As per the below remark, if we are to use libltdl for other things in
NUT, there is an interest in embedding this code.
Otherwise, if it's only needed for nut-scanner, it will probably be
better to leave that dependency external, and condition nut-scanner
compilation to this.
> Moreover Arnaud seems to have plans for some sort of plug-ins for upsd
> (I will let him elaborate if needed). The chosen dynamic link solution
> we will choose could be used for these plug-ins too.
this is true for upsd and also for drivers.
We have been talking for some time of cleaning and modularizing the
dstate / state layer (communication layer between drivers and upsd),
to provide a better support for other channels (HAL, UPower, ...). We
could also use DBus on Linux for example. Though that introduce other
problems.
upsd on its side could provide plugins, beside of the classic NUT
protocol, for SNMP (agent), MQ (RabbitMQ, ...), ... to provide its
data to a wider range of systems. MQ are for example widely used in
big infra (datacenters, cloud).
>From a design point of view, I'm still unsure if it's better to have
upsd + plugins, or a set of daemons that provide these various
protocol interface.
> Please send your comments and suggestions about libltdl and more
> generally on this dynamic link issue.
Feedback and comments welcome.
cheers
Arnaud
--
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/