Re: git: cf25897f304e - main - lang/go119: Update to 1.19.5

On Wed, Jan 11, 2023 at 1:44 PM Dmitri Goutnik <dg@syrec.org> wrote:

> On 11/01/2023 13:13, Emmanuel Vadot wrote:
> > On Wed, 11 Jan 2023 10:58:14 -0700
> > Adam Weinberger<adamw@adamw.org>  wrote:
> >
> >> Ahh okay, I wondered what the calculus on that was!
> >>
> >> It seems a little odd to me to only bump for security changes. Given
> that
> >> all go binaries are statically linked from the go stdlib, upgrading go
> >> alone does nothing for the entirety of go ports.
> >   It does not do nothing, in fact it does a really bad thing which is
> > that we now have different package result for all go ports that what is
> > currently in the package repo (official or not).
> >   Also since the builder always bulk -c (I think) this means that if a
> > user install whatever go package today and another user install the same
> > package after the next build they will have different package. And if
> > this go update actually fixes a bug that is present in this package it
> > means that the first user will have the bug and not the second one, so
> > it causes headache for PR.
> I will bump revisions, but the same problem exists with Rust, Crystal
> and anything else that builds
> statically linked executables.
>
> My perception of this issue is less dramatic, but if it seems super
> important then perhaps revision bumps
> shouldn't be left to committers and pkg and/or poudriere could record
> the Go version that packages were
> built with and do rebuilds automatically as needed. It seems that only
> FreeBSD does these massive revision
> bumps, neither Arch, Debian or OpenBSD are doing that (I don't know
> whether their packaging infrastructure
> handles rebuilds automatically or they just don't see the need).
>
> Also, there's a whole another can of worms that is quarterly, where
> these revision bump commits are
> practically unmergeable.
>

It absolutely is a slippery slope and it's not just hypothetical.

Less than an hour ago, I emailed portmgr about adding a simple and central
way to bump things for go/rust/crystal/etc. My thought involves adding a
new suffix, something like ~n, where n is defined in go.mk/rust.mk/etc.
It'd be a monotonically-increasing number, where pkg gives it higher
precedence than PORTREVISION. Anything using USES=go/rust/etc. would pick
it up.

It'd make version numbers look even more like line noise (foo-1.2.3_4~5,6)
but would allow a one-line change to apply to everything, and would also
trivialize quarterly merges.

I have a tendency to dream up over-engineered solutions without a problem,
but I think this is a problem that actually needs solving. I'm curious what
you all think.

# Adam


-- 
Adam Weinberger
adamw@adamw.org
https://www.adamw.org