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

On Thu, Jan 12, 2023 at 1:06 AM Baptiste Daroussin <bapt@freebsd.org> wrote:

> On Wed, Jan 11, 2023 at 01:51:27PM -0700, Adam Weinberger wrote:
> > 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
>
> Here the proposal is too simplistic and at least requires more thought to
> be
> implemented (reason why I haven't implemented it). It requires work both in
> bsd.port.mk and pkg (at the very least)
>
> Some of the reasons are the following (not exhaustive):
> - what happen is a port uses 2 of the languages which implement a ~number?
> how
>   do we combine?
>

Add all the numbers, I suppose, though it'd be a shell call to do the
addition...


> - how is the version numbering going on? monotonic? in the case we
>   will quickly endup with mygopkg-1.2.3_4~12953532976432096,6, do we
> really want
>   that?
>

To be fair, it's unlikely for there to be trillions of go versions. Even
100 go version updates would take many, many years. I doubt such a number
would ever reach 4 digits :-)

> It is also incomplete to solve the "hell" of those kind of packages:
>
> If we are to really chase properly the packaging of those packages we
> should
> also track any changes of any of the dependencies which end up bundled
> (crates,
> go modules, etc.) in the final packages, to make sure we also bump the
> revision
> as soon as any of them is has a security issue for example. how do we flag
> this
> change (locally PORTREVISION? globally
> yetanotheradditiontotheversionnumber?).
>
> This is the level of thinking I think we should have for this type of
> packages.
>

I don't disagree, but there's a simpler and more immediate problem where we
ought to bump go/rust/etc. ports more often, and it doesn't happen a lot of
the time because it's difficult. Addressing that may pave the way for
future work. Is it really better not to address a simple problem because a
more complex one exists orthogonally?


> Btw this discussion should not happen in portmgr, but in ports@ so anyone
> can
> participate and provide ideas and fresh view.
>
> Reminder it is not up to portmgr to do all the infrastructure work, it is
> up to
> portmgr to ensure the consistency of this infrastructure work, it is up to
> all
> of us to change bsd.*.mk if needed :D
>

This is definitely true. I have a tendency to reach out to portmgr first
mostly for thoughts and advice before bringing it to ports@. Part of
portmgr's advantage is seeing the big picture, and more importantly I count
the group as friends. If it feels like an end-run, I can stop doing that,
but it has always felt to me like a good place to turn to for help with
framing an idea so I can present the ports group a more fully-formed
proposal.

# Adam


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