[Nut-upsdev] 2.8.1 build buglet: sockdebug.c

[Greg Troxel]

Jim Klimov <jimklimov+nut at gmail.com> writes:

> Thanks, I think it would not hurt to add the variables into the source if
> that helps?

I realized that the package defines --with-dev, which seems obviously
wrong, so I removed that.  With that gone, the build no longer includes
sockdebug, so I don't need a patch.

> A bit puzzled why it wants TCP wrappers though, the program is primarily
> about the Unix socket access.

The program does not want TCP wrappers.  It is just that Makefile.am
puts the wrapper libs in LDADD.   tcpwrappers are odd in that for most
libraries if you just randomly add them to some program that does not
use them, nothing happens.  But AIUI, you can't add libwrap unless you
define those variable.

> It can be used by end-users or more likely by developers for
> troubleshooting; potentially for some automations that act like a NUT
> driver. Not intended as a prime-time mechanism, but could have its uses...

ok, seems just as well to omit.   packaging really should not turn on
--with-dev; that's what --with-dev is supposed to mean.

> As for the name, it is supposed to be installed into `--libexecdir` by
> default, where it might indeed confuse or collide (if using the common
> system path by silent default). Package recipes I've seen recently had used
> customized paths like `/usr/libexec/nut` similar to how `sysconfdir` is
> `/etc/nut` or `/etc/ups` (not using silent default `/etc`), so did not
> think much of it.

I see that libexec has a lot, and my package already uses
/usr/pkg/libexec/nut, so there is no confusionn.

> Regarding the release rituals - it is a bit more than 3 minutes, poking
> here and there (nut-website snapshots, github release drafting, and stuff),
> but after a few iterations it at least got decently documented in
> maintainer notes. Also helps to not remember it from scratch after a
> decade, but actually *remember*from a more recent experience :)
>
> The annoying thing with "urgent" releases is moving GitHub milestone tasks
> (what we expected to implement here in a leisurely cadence), which suddenly
> are not getting completed in the predicted release number, to another
> milestone. But this is also not a prohibitive show-stopper...

Sure, I realize it's more to make it.  I just meant that the total work
imposed on packagers is not high.  And, generally we want to be able to
say "update to the latest formal release before complaining".

I wasn't thinking of milestones (there really should be a bulk move
operation), but I suggested 2.8.1.1 as being exactly 2.8.1 plus a
bugfix.