Re: policy proposal: updating packages with many dependencies

[Thomas Klausner <wiz%NetBSD.org@localhost>]

On Wed, Mar 19, 2025 at 01:38:24AM +0000, David Holland wrote:
> On Tue, Mar 18, 2025 at 02:06:28PM +0100, Thomas Klausner wrote:
>  > Before committing non-micro version updates to any of the following
>  > packages:
>  >   [snip]
>  > 
>  > a limited bulk build of meta-pkgs/bulk-test-${PACKAGE} needs to be
>  > run and the result posted to tech-pkg, highlighting what packages
>  > would stop building (if any).
>  > 
>  > Depending on the result, pkgsrc-pmc then decides:
>  > 
>  > - go ahead with the update
>  > 
>  > - wait for packages X, Y, Z to be fixed (upstream or locally) with the
>  >   updated version, which is put in wip in the meantime
>  > 
>  > In the second case, all pkgsrc developers are encouraged to work on
>  > fixing this - it is not only the updater's task to fix them.
>  > 
>  > The decision to wait for packages can be revisited.
> 
> Seems reasonable, with one suggestion: when we finally boot cvs, we
> should use branches for this rather than wip. Fewer things to mess up,
> can merge atomically (might be necessary for lockstep updates of
> certain things), a lot easier to capture the state with more bulk
> builds, etc.

Yes, I'd like to use branches for that. A wip package is the best we
can do now, but makes testing hard since you'd have to adapt all
buildlink3.mk includes to use that location.

> (long-running-style development branches, I'd think, not the rebase or
> merge-squash kind.)
> 
>  > - go
> 
> Isn't every new go version a new package, so the concern is not about
> committing that package but about bumping the default vesrion?

Yes, you're right. Let's remove go from this list - it's a separate,
similar discussion for updating the default version of packages like
Go, Python, and PHP, which we can have another time.
 Thomas