From nobody Thu Jan 12 18:13:39 2023 X-Original-To: dev-commits-ports-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NtCNj1xMgz2pJ3Z for ; Thu, 12 Jan 2023 18:13:57 +0000 (UTC) (envelope-from adamw@adamw.org) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NtCNj1hcTz4CNJ for ; Thu, 12 Jan 2023 18:13:57 +0000 (UTC) (envelope-from adamw@adamw.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x633.google.com with SMTP id az20so27684499ejc.1 for ; Thu, 12 Jan 2023 10:13:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamw-org.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/TwHWo1rMRCkuizm1eerGnUZmJOQ/bsirMpWZ7a1njM=; b=7XQpoFE8odHzpv8au1+wBzOG/d2htqoOuqreRaHWWRf3F30hMiL/YGAseDhtSSajCt T5pTUJT+pKnctcZeb8ZKKZAuN6doFW22rbSFNnjv/8Fb7wx0KN56jZlyOHu6B3O5ZTGu rIsg2/665lmhwGpg6cruHWSaErEYUC2lzMblcdbBkipCkdESIIwyLa23VpUx4Oc9j5CL 8MAks9Aq0wAQItXii/ROij+7Oe5GfGgw+Ryc1JfMKC3HAn2ulU/zH6NN4wQaNIMicSwe ZVlomiAEC9kQz8S8GbO83JqEHqhu1uotdY+DYPqOLQBvC08gvmp7WqE8xYLXbx145UEV eovw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/TwHWo1rMRCkuizm1eerGnUZmJOQ/bsirMpWZ7a1njM=; b=ISSIRPUvKF/wzRqZdB5SLHRAnEI+uKTR+2ACoEMxLX0tTUr5DDuvbN+nT6n/V4eE7V Ok5bPN1Fcso+P7zMHp8dYDEwp5v4Kt5KvkDqBfpN0q/iyxqZSlFj3pXnNQRsMWg8Jegg FUJSDym2GXnvlmw2ZaOBDHaSLyjjD+LyGxriD4Wcrx3h98jcVsxLuxG3P79bW7J+2WBv 3FcBQ2tO0vCQa77UQNqBqaOM582uSm4148XZjuBoUypTbOXrGhmY17Yk4t6wlAZd2Tam Ao9DPcDsKr2y6+JAb9a6nLByKRJNevzCZjBOOVE0zO8ZXSYTJDOWNOrldkxoD8eFcBgM 5ymA== X-Gm-Message-State: AFqh2kpdvLTnrZpwuzdSURqi+JUIuZGnWshIpwOx97hLn3M6sSlZdpsv a6BaDKtg+sgFpz9jP/8x7DqFwZX/x8E4dLbrabR35A== X-Google-Smtp-Source: AMrXdXtXrFGzInPFvRK4tBtVsIQZ2z95/BjQJcLqYxlXhfPjtyIbEF6cJ/lmOKdsP5jo7chilxVXWYiC8K9qW36iX4g= X-Received: by 2002:a17:907:2917:b0:838:1b80:9a7b with SMTP id eq23-20020a170907291700b008381b809a7bmr10053472ejc.708.1673547235821; Thu, 12 Jan 2023 10:13:55 -0800 (PST) List-Id: Commit messages for all branches of the ports repository List-Archive: https://lists.freebsd.org/archives/dev-commits-ports-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-ports-all@freebsd.org X-BeenThere: dev-commits-ports-all@freebsd.org MIME-Version: 1.0 References: <202301111401.30BE1eAN069454@gitrepo.freebsd.org> <8a2d2724-75f5-ec2a-41af-5b353acb3aa0@syrec.org> <20230111191326.226f0b0346f61136055e62fa@bidouilliste.com> <7bed3cdc-a3f2-a768-e6ab-355b524f9ea2@syrec.org> <20230112080652.e5lzd7m727oabgdp@aniel.nours.eu> In-Reply-To: <20230112080652.e5lzd7m727oabgdp@aniel.nours.eu> From: Adam Weinberger Date: Thu, 12 Jan 2023 11:13:39 -0700 Message-ID: Subject: Re: git: cf25897f304e - main - lang/go119: Update to 1.19.5 To: Baptiste Daroussin Cc: Dmitri Goutnik , Emmanuel Vadot , Dmitri Goutnik , ports-committers@freebsd.org, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org Content-Type: multipart/alternative; boundary="000000000000819bed05f21514b7" X-Rspamd-Queue-Id: 4NtCNj1hcTz4CNJ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000819bed05f21514b7 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 12, 2023 at 1:06 AM 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 wrote: > > > > > On 11/01/2023 13:13, Emmanuel Vadot wrote: > > > > On Wed, 11 Jan 2023 10:58:14 -0700 > > > > Adam Weinberger 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 --000000000000819bed05f21514b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jan 12, 2023 at 1:06 AM Baptis= te Daroussin <bapt@freebsd.org&g= t; 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>=C2=A0 wrote:
> > >
> > >> Ahh okay, I wondered what the calculus on that was!
> > >>
> > >> It seems a little odd to me to only bump for security ch= anges. Given
> > that
> > >> all go binaries are statically linked from the go stdlib= , upgrading go
> > >> alone does nothing for the entirety of go ports.
> > >=C2=A0 =C2=A0It 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 t= hat what is
> > > currently in the package repo (official or not).
> > >=C2=A0 =C2=A0Also since the builder always bulk -c (I think) = this means that if a
> > > user install whatever go package today and another user inst= all the same
> > > package after the next build they will have different packag= e. 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 seco= nd one, so
> > > it causes headache for PR.
> > I will bump revisions, but the same problem exists with Rust, Cry= stal
> > and anything else that builds
> > statically linked executables.
> >
> > My perception of this issue is less dramatic, but if it seems sup= er
> > important then perhaps revision bumps
> > shouldn't be left to committers and pkg and/or poudriere coul= d 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 nee= d).
> >
> > 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.<= br> >
> Less than an hour ago, I emailed portmgr about adding a simple and cen= tral
> 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<= /a>.
> It'd be a monotonically-increasing number, where pkg gives it high= er
> precedence than PORTREVISION. Anything using USES=3Dgo/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 al= so
> trivialize quarterly merges.
>
> I have a tendency to dream up over-engineered solutions without a prob= lem,
> but I think this is a problem that actually needs solving. I'm cur= ious what
> you all think.
>
> # Adam

Here the proposal is too simplistic and at least requires more thought to b= e
implemented (reason why I haven't implemented it). It requires work bot= h in
bsd.por= t.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
=C2=A0 do we combine?

Add all the numbers, I s= uppose, though it'd be a shell call to do the addition...
=C2=A0
- how is the version numbering going on? monotonic? in the case we
=C2=A0 will quickly endup with mygopkg-1.2.3_4~12953532976432096,6, do we r= eally want
=C2=A0 that?

To be fair, it's unlikely for ther= e to be trillions of go versions. Even 100 go version updates would take ma= ny, many years. I doubt such a number would ever reach 4 digits :-)
It is also incomplete to solve the "hell" of those kind of packag= es:

If we are to really chase properly the packaging of those packages we shoul= d
also track any changes of any of the dependencies which end up bundled (cra= tes,
go modules, etc.) in the final packages, to make sure we also bump the revi= sion
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 packa= ges.

I don't disagree, but there's a s= impler 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 d= ifficult. Addressing that may pave the way for future work. Is it really be= tter not to address a simple problem because a more complex one exists orth= ogonally?
=C2=A0
Btw this discussion should not happen in portmgr, but in ports@ so anyone c= an
participate and provide ideas and fresh view.

Reminder it is not up to portmgr to do all the infrastructure work, it is u= p 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 defin= itely true. I have a tendency to reach out to portmgr first mostly for thou= ghts and advice before bringing it to ports@. Part of portmgr's advanta= ge is seeing the big picture, and more importantly I count the group as fri= ends. 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


--
--000000000000819bed05f21514b7--