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@alioth-lists.debian.net> wrote: > Jim Klimov via Nut-upsuser <nut-upsuser@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@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
