Nut upsuser - Aug 2024 - Question about nut-dependencies

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>

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net>
writes:
> Upsmon as such has no need for XML (libneon et al); that would be
> nut-scanner and the Eaton NetXML protocol driver.
Sure, but it is normal for packaging systems to build the entire
project, so that whatever someone wants is available, and thus depend on
the union of the dependencies.   That's what ups-nut more or less
suggests by building everything at once, instead  of having N separate
tarballs to be built/installed.

The art is choosing how much grief to goto to make split packages,
guessing on who wants what, and who won't already have the dependencies.
Things like libxml are IMHO not a big deal; qt on the other hand is a
major problem, to pick an extreme (for a program that is not a
using-facing qt app; for qgis it's fine).