2011/12/5 Frédéric Bohé <[email protected]>: > 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/ _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
