[Nut-upsuser] Network UPS Tools version 2.2.2-pre2 released
aquette.dev at gmail.com
Wed Apr 23 16:17:33 UTC 2008
2008/4/22, Arjen de Korte <nut+users at de-korte.org>:
> 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
> > > .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... :-)
Have a nice and deserved break with your family.
recharge your batteries the more you can. the 2nd born is really a big step ;-)
> > 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.
not sure to understand the latter...
> > 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?)
well, I'm not sure since it depends on how an upgrade will behave with
the paths official <-> nut-ones.
More information about the Nut-upsuser