[Nut-upsuser] Network UPS Tools version 2.2.2-pre2 released

Arjen de Korte nut+users at de-korte.org
Tue Apr 22 17:54:08 UTC 2008

Arnaud Quette wrote:
>>  In the mean time, I have divided the main 'nut' package in the
>>  following sub packages:
>>  - nut (client applications)
>>  - nut-server (drivers and upsd server, requires 'nut')
>>  - nut-snmp (net-snmp based SNMP driver, requires 'nut-server')
>>  - nut-xml (neon based XML driver, requires 'nut-server')
>>  - nut-cgi (web interface, requires 'nut')
>>  - nut-hal (HAL drivers, conflicts with 'nut')
>>  - nut-devel (libupsclient library, requires 'nut' (?))
>>  I think this should more or less suit most needs. I'll prepare an updated
>>  .src.rpm later today or tomorrow.
> great! Any news from Stan btw?
No, not yet. I haven't asked him yet. I'm actually quite busy preparing 
for a two weeks leave. Our last holiday before Junior is born... :-)
> A side note on nut and nut-server: I've thought about that in the
> past, and come to the conclusion that nut should be a meta package
> (either depending upon nut-client + nut-server, or asking (like with
> debconf) for the flavor to be installed ; ie classic
> standalone|client, hal, ...).
> Then you have nut-client,  nut-server, ...
For the moment I made the split like it is. There is not much point in 
running anything NUT related without either the clients or HAL drivers, 
so the starting point is basically 'nut' or 'nut-hal'. The latter pretty 
much excludes 'nut-server', but you could run a client alongside it (I 
got my conflicts wrong there). Running a server without clients is 
useless most of the time (some bizarre configurations aside), so having 
'nut' is a requirement. And lastly, the 'nut-snmp' and 'nut-xml' drivers 
are worthless without 'nut-server'.
> I also come to the conclusion that we won't be able to have a uniform
> implementation (ie the same packages split) on all supported systems.
I'm afraid we won't. This shouldn't be too bad, provided we have list of 
people that run as many platforms that we know of.
> But we should:
> - provide advices and shared resources (packages descriptions,
> translations, LSB init scripts, ...). That will still be addressed by
> the NUT Packaging Standard
> - provide the needed helpers to deal with these differences and the
> needs of config / client UI. So an upsconfig library should provide
> functions to query the various paths, user/group, ...
> I'm also updating the debs on my side, both merging the last official
> one for -pre3 and updating these (adds the nut-xml package)
Should I make one available for openSUSE as well (the version *we* like, 
not necessarily the one that is bundled by openSUSE?)

Best regards, Arjen

More information about the Nut-upsuser mailing list