Hi Arjen, 2008/4/22, Arjen de Korte <[EMAIL PROTECTED]>: > 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... :-)
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'. right > > 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. cheers, -- Arnaud _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser