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

On Thu, Jan 12, 2023 at 10:11:03AM +0100, Mathieu Arnold wrote:
> On Thu, Jan 12, 2023 at 09:06:52AM +0100, Baptiste Daroussin 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?
> > - 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.
> 
> Maybe we should look at how Arch Linux does it, whenever something in
> the dependency chain of, for example, some haskell package gets updated,
> the revision of the package gets bumped.

Yes I though about a "BUILD_DEPENDS_SENSITIVE" or something like that, but it
means that PORTREVISION cannot be handled anymore via bsd.port.mk but should go
via a script (make(1) cannot do math as far as I can tell).

Also we need to be able to determine  which of the BUILD_DEPENDS requires to
bump the revision.

Last it means we have a state of the last build for each packages somehow which
by design does not exist (for us) but do exist for Arch and most of the linux
distribution.

Note: If we could do it, it will solve the specific case of "if some of my build
dependency changes then I need to rebuild the packages" which is a good first
step, but it does not solve the pb of the bundle modules.

Best regards,
Bapt