I am new to the email list and a recent fan of the NUT software. I have been deploying Windows, Ubuntu, and MacOS clients. I am dealing with very old machines, attempting to keep them running at an office where they cannot upgrade the machines due to software dependencies. I was recently trying to get a client using Mac Ports and it would not build on my target machines, MacOS 10.5 and 10.6 due to a linker error, unknown compiler option. Investigating I ran into this Mac Ports ticket: https://trac.macports.org/ticket/41789 While I was able to get a build using fink and obtain statically linked binaries for distribution, I had a larger question for those maintaining the code base. 1) Who is deciding what goes in to fink and port packages? Do the maintainers of NUT have any say with fink, Mac Ports, and Home Brew (for MacOs machines)? 2) Does anyone re-evaluate dependencies like in that ticket, where a dependency on 'libproxy' was added as a 'neon' that pulled in a bunch of larger dependencies like big packages like gtk? It would seem advisable, in the case of Mac Ports, to lock in the sub-package neon @0.29.6_2 and not pull in a litany of other dependencies for a small utility like upsmon? Finally, thank you to all who continue to maintain the project. It is a great set of utilities.>From: Jim Klimov <jimklimov+nut at gmail.com> >To: Greg Troxel <gdt at lexort.com> >To that tune, here with NUT being animportant cog to keep >machines>running, even those who might struggle due to respectable age, there is >some deliberate effort to support 25 years' worth of dependencies so that >current NUT can be built as far back as CentOS 7 or Solaris 8.-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240821/9256868f/attachment.htm>
Packaging issues would be brought up with the distro... I have recently worked with Homebrew on a Mac VM for the CI farm, but otherwise have no clue about the ecosystem. Last saw/touched a physical Mac in school, 1994 or so :D Upsmon as such has no need for XML (libneon et al); that would be nut-scanner and the Eaton NetXML protocol driver. On Wed, Aug 21, 2024, 18:59 Heath Smith via Nut-upsuser < nut-upsuser at alioth-lists.debian.net> wrote:> I am new to the email list and a recent fan of the NUT software. I have > been deploying Windows, Ubuntu, and MacOS clients. I am dealing with very > old machines, attempting to keep them running at an office where they > cannot upgrade the machines due to software dependencies. > > I was recently trying to get a client using Mac Ports and it would not > build on my target machines, MacOS 10.5 and 10.6 due to a linker error, > unknown compiler option. > > Investigating I ran into this Mac Ports ticket: > > https://trac.macports.org/ticket/41789 > > While I was able to get a build using fink and obtain statically linked > binaries for distribution, I had a larger question for those maintaining > the code base. > > 1) Who is deciding what goes in to fink and port packages? Do the > maintainers of NUT have any say with fink, Mac Ports, and Home Brew (for > MacOs machines)? > > 2) Does anyone re-evaluate dependencies like in that ticket, where a > dependency on 'libproxy' was added as a 'neon' that pulled in a bunch of > larger dependencies like big packages like gtk? It would seem advisable, in > the case of Mac Ports, to lock in the sub-package neon @0.29.6_2 and not > pull in a litany of other dependencies for a small utility like upsmon? > > Finally, thank you to all who continue to maintain the project. It is a > great set of utilities. > > >From: Jim Klimov <jimklimov+nut at gmail.com> > >To: Greg Troxel <gdt at lexort.com> >To that tune, here with NUT being an > important cog to keep >machines > >running, even those who might struggle due to respectable age, there is > >some deliberate effort to support 25 years' worth of dependencies so that > >current NUT can be built as far back as CentOS 7 or Solaris 8. > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240821/2ae8eff0/attachment.htm>
On Aug 21, 2024, at 12:34?PM, Heath Smith via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> wrote:> > 1) Who is deciding what goes in to fink and port packages? Do the maintainers of NUT have any say with fink, Mac Ports, and Home Brew (for MacOs machines)? >As Jim mentioned, the distributions like Fink and MacPorts are free to choose the subset of dependencies that they can easily handle. Speaking as someone who coincidentally maintained the NUT package in Fink for a few years, it can be tricky to strike a balance between complexity and maintainability, and altering that dependency chain usually takes quite a bit of testing. I no longer have a working Fink install, so I would have to rely on others to test any changes. That said, since Fink moved their package tree to Git a few years ago, it is not too hard to maintain a patch against upstream to trim down the dependencies. If you don't need the Eaton NetXML driver and its dependencies like neon, don't build it. You can change any "BuildDepends: foo" to a "BuildConflicts: foo", and remove the splitoff that packages that up (e.g. https://github.com/fink/fink-distributions/blob/master/10.9-libcxx/stable/main/finkinfo/net/nut.info#L225 ). Sometimes there are ./configure options that need to be removed as well, but usually the BuildConflicts will prevent the library from being visible to the configuration process. Similarly, low-level USB support on MacOS has been withering away for some time now. It is especially difficult to detach the incumbent USB HID PDC driver, to the point that I wrote a separate NUT driver (macosx-ups <https://networkupstools.org/docs/man/macosx-ups.html>) to read from the system power monitoring code. libusb doesn't have a ton of dependencies, but it too is a candidate for the chopping block, especially if you are just monitoring a remote UPS on non-Mac hardware. I'm not sure what that patch process looks like for MacPorts or Homebrew. -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240821/d8a66438/attachment.htm>