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/4bbd394b/attachment.htm>