Re: policy proposal: updating packages with many dependencies

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

David Holland <dholland-pkgtech%netbsd.org@localhost> writes:

> 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.

Sure, but if a depending package can be fixed to work with both old and
new, that's better, and can be committed as the fixes happen.

> (long-running-style development branches, I'd think, not the rebase or
> merge-squash kind.)

I agree not squash, but I generally favor rebasing for clarity and I
don't think we should have a norm to avoid it.  That's VCS religion
territory and there's no need to agree for this proposal.

>  > - 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?

(I see go has been moved to 'default version change' and out of this.)

We already have a group norm, not expressed as policy, that we discuss
before changing the default version of versioned lanaguages.  I think it
would be good to formalize that, and add pgsql/mariadb and a few other
things.   But, because discusssion as ~always happened, that's more
housekeeping than addressing problems.