[Nut-upsuser] UPS configuration issue?

[Greg Troxel]

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> writes:

> Per https://www.debian.org/News/2023/20230610 they released the 12th
> (bookworm) baseline on June 10, 2023, and `bookworm will be supported for
> the next 5 years` (after handing off to community after first 3 years, per
> https://wiki.debian.org/LTS).
>
> The packages that go in a new release are finalized a couple of months
> (give or take) before the stable release.
>
> Per https://networkupstools.org/, git tags and whatnot, "Apr 26, 2022: NUT
> 2.8.0 released" and "Oct 31, 2023: NUT 2.8.1 released" - so at the time
> they had no other NUT to put into the baseline than the newest (at the
> time) 2.8.0. And it's great they made the effort and did not ship 2.7.4
> again :D
>
> As I said before, "Stable" may mean "stale", but primarily it is
> "unexciting" - no cutting edge features, but also no surprises and bugs for
> you being the first to discover after a couple of years of use and interim
> minor updates. It is not only about lack of volunteer time (and as the
> adage goes, staying on the outside and donating a bit sometimes can not
> help the people doing actual work in addition to a dayjob, to run longer
> sleepless nights or stretch longer family-outing-less weekends), but also a
> matter of policy when you name something a stable distro lineage. This
> inclination to minimal change (focusing only on bug fix backports) is
> precisely what makes it stable.

Indeed.  Packaging systems like Debian intentionally pick a version and
stick with it.  If that's what you want, that's fine, but if it's not,
maybe $someone should pick something else.

The real problem is that people that release things like NUT don't want
to debug old versions, and it's not reasonable to ask them to do so.
For a different project I maintain, there's a hard rule in the bug
tracker that bugs are accepted only against the most recent formal
release (or the tip of master).

With Debian, it's at least a community-supported Free Software project,
and as Jim says there is great merit in stability, so I don't fault
Debian.

With Red Hat, I am not really ok with the culture of RHEL users
expecting upstreams to either support old versions or to keep the
current version building on some really ancient set of prereqs.

> People who want a more dynamic workstation or server can build their own,
> add repos for specific newer packages (either way, making software combos
> that distros can not test as a near-infinite matrix - so it is a mix of
> luck and API stability that keeps these mostly working in practice) or
> fully stay on an "experimental" or "sid" repository instead of a particular
> stable release, etc.

Or they can use pkgsrc, and build /usr/pkg with nut and dependencies,
and not change their stable base.  Or build by hand.

> BYO became something we have to encourage with NUT bug reports/suspicions
> made against older releases, and many man-months went into documenting and
> automating in-place rebuilds and recipe performance+stability to make it
> easier for "laymen". After all, a NUT release is also "stale" a few days
> after the cut-off point, as new features and bug fixes begin pouring in.

I don't think it 'became something'.   Building from source is the
longstanding norm in Free Software, and packaging systems are a way to
save time.