Re: policy proposal: updating packages with many dependencies

[Greg Troxel <gdt%lexort.com@localhost>]

Jonathan Perkin <jperkin%pkgsrc.org@localhost> writes:

> * On 2025-03-19 at 12:44 GMT, Greg Troxel wrote:
>
>>A few years ago I would have suggested cmake be on this list, but it
>>seems upstream is more stable now, and I don't remember recent troubles.
>
> The recent changes where they go out of their way to break the use of
> WRKOBJDIR=/private/tmp on macOS for absolutely no good reason would
> suggest otherwise:
>
>   https://github.com/drecklypkg/dreckly/blob/ci/cmake-cleanup/devel/cmake/patches/patch-Source_kwsys_SystemTools.cxx
>
> I personally wouldn't trust any cmake updates.

Fair enough.  I was thinking of larger-scope meltdowns, which I have bad
memories of from maybe 5 years ago.

I would say then let's put (non-micro) cmake on the list for
discuss-first, without prejudicing the discussion should "should we hold
cmake to 2, 4, ?, or unlimited updates in a year".

On the logically separate but in this email :-) limiting-cmake
dscussion, my impression is that cmake has too many releases for what
ought to be a stable foundational tool.  It looks like 3.Y.0 is released
about 3 times a year.  I really don't understand why, and agree with
your point that it doesn't need to be new in pkgsrc.  Upstreams seem to
support quite old cmake, partly due to just not bumping minimum versions
gratuitously and partly because of accomodating LTS culture.

Given all that, I could see us choosing to update cmake in January and
July, ~immediately post branch, and to pick the highest micro of the
release that's been out for at least 3-6 months at the time.  Or just
January, to be revisited if there is a problem with it not being new
enough.

The part of what I think you want that is harder is not updating to new
micros.  Updating seems ok stability wise, but it does trigger bulk
rebuilds.  It doesn't seem right to be to avoid bugfixes because of cpu
time, when rebuilding is a choice.

I wonder about adding a feature to pbulk where for build tools, a newer
micro than was used will be considered good enough and thus not require
rebuilding, and people doing continuous builds could leave this on,
flipping it off occasionally to choose when to take the hit (and take
fewer hits because of merging them).