Re: policy proposal: updating packages with many dependencies

[nia <nia%NetBSD.org@localhost>]

On Thu, Mar 27, 2025 at 10:43:34PM +0100, Thomas Klausner wrote:
> The 'abi' point matches, I think, what I proposed - packages that have
> caused problems before because of ABI (or API) changes.

The goal of restricting updates here should be moving to a system
of versioned packages like multimedia/ffmpegX, where each ABI/API
break results in a new package being created, and packages get
slowly swithced over as they are tested with the new version.
This is a model that's pretty much been proven to work.

If you want to update the package without comprehensive and
lengthy testing, you should be prepared to rework the package
to be versioned.

> IMHO, 'lts' does not fit here. I think the proper solution for this is
> having foo and foo-lts packages, like the ESR packages we have for
> firefox; perhaps with some kind of lts.mk files that globally switch
> to the lts or the HEAD version, if other packages depend on them.

This concept needs work, we're currently in a situation where
users of binary packages install "firefox" because they believe
it's the most recent version, when e.g. firefox128 may well have
more recent security fixes.