[Nut-upsuser] Question about nut-dependencies

[Heath Smith]

For the casual user pulling packages using apt-get (Linux) or, in the case
of MacOS, ports, fink, and Homebrew, they are not going to dig in to the
make support. For myself, I want to do the same, just build the binaries.
Hacking these package managers to affect the compiler and linker options as
an end-user is not an easy task.

On a side note, if glib2 is dropping support for older platforms, it is
just a matter of time before NUT will not build on older platforms, based
on when those managing the dependencies decide to break with the past.

https://gitlab.gnome.org/GNOME/glib/-/issues/3437#note_2195247
https://gitlab.gnome.org/GNOME/glib/-/issues/3441

Just a thought.


On Wed, Aug 21, 2024 at 5:42 PM Jim Klimov <jimklimov+nut at gmail.com> wrote:

> Well, NUT does "since forever" have reference docs on packaging into 8 or
> so entities each with its dependency tree, so heavy stuff can be pulled in
> on a need-to-have basis. As anything, it can be improved and updated, but
> it is there and many systems follow it. Those who missed the memo... the
> onus is on them.
>
> The `nut-scanner` tool (and its lib) design using run-time `dlopen()` of
> available dependencies (might be pulled for drivers the particular system
> needs) instead of "normal" linking with everything at build time pursues
> the same goal, as far as its package-required footprint goes.
>
> Jim
>
>
> On Wed, Aug 21, 2024, 20:28 Greg Troxel via Nut-upsuser <
> nut-upsuser at alioth-lists.debian.net> wrote:
>
>> 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).
>>
>> _______________________________________________
>> 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/0e3b1f0f/attachment-0001.htm>