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

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

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.

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

Baptiste