From nobody Wed Jan 11 20:51:27 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 4NsfxD61Rnz2r7bL for ; Wed, 11 Jan 2023 20:51:44 +0000 (UTC) (envelope-from adamw@adamw.org) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 4NsfxD3xS1z3k6s for ; Wed, 11 Jan 2023 20:51:44 +0000 (UTC) (envelope-from adamw@adamw.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x634.google.com with SMTP id jo4so39957736ejb.7 for ; Wed, 11 Jan 2023 12:51:44 -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=9/j0UWLr550CaVqO/AZ8o6FuAMezleEDMUUf0ceq+p8=; b=b3wAMwL1HILolupGlN/HuZBNnZOMg+whwpF48MrhsoBjKNQ+bMpEpYykX3uK7leSfd kqB6MbdXbWjyR8DXIy2GYFO+0ggaeE9rh+jtei0yf8d5mfzoR7T5RFfyTUM72bvHCfF5 AAHpcd3Tmlajl+0whRzXacJPUNL/6hWjB3comGM5MciPNqfLbM8CmiPHCOVOkGqAsuZe 6ur23UkYLB0BJMsbJ8UL0fTXvxjK+Qx4vq15wDFK4MGeSFIQnVdJ3yy8cU2Pi7lwczU/ VQ3tcw4GfdPEIuOm9kLDwnb/1ZJv4+QxDubw3WrTzkIUwFAAtX6YCeEPaQUcsy07FsN2 Kzag== 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=9/j0UWLr550CaVqO/AZ8o6FuAMezleEDMUUf0ceq+p8=; b=El9+DziywzJ0ayLqveB/9ww48Uigsha4960F9gCCI5lad86h7HNoBeqSm+nKtB55ft 6OyxLW63/eOXIAlTpCkDMIClFiwy92EYR4CDRx1ewhFsESajM20Fg/2W57WncBDTxGJ8 FAM3oLURwkiaP/20vhNeiyP5krJpfxVtzf7/AE3x1Uaro1UiU/2Tw+HMdOXWS9TkjDhP peSm0auWM0gDRYhwEvVo88kedOcjXnBmUV2IfDSTQunibj0npvBg6HyIE+43prsWi73X lU+/eWvOtuY3omnmPvEDngvT8P2EJiuS8aibSLGTarCZa0E1gZptc366Sr23gtj4rNQk xzlw== X-Gm-Message-State: AFqh2kpmx+ZIVceml6J6cJFnSuWePbOSWqO/AllycKKTMg7vo3CuTgxe VCXnyvE1dkvVQlkOcPJoSiH6y1HmkMZQBgHJDzQNfg== X-Google-Smtp-Source: AMrXdXubXu8m2C8olOxnjAmor3267oTe1bNE9buyvCE4X2Q7ltJVzkY4uzDqNJxqhSoQJKIBh2Izhrqq4+hxI1UuPMw= X-Received: by 2002:a17:906:7ac8:b0:840:758a:9157 with SMTP id k8-20020a1709067ac800b00840758a9157mr4212258ejo.434.1673470303302; Wed, 11 Jan 2023 12:51:43 -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> In-Reply-To: <7bed3cdc-a3f2-a768-e6ab-355b524f9ea2@syrec.org> From: Adam Weinberger Date: Wed, 11 Jan 2023 13:51:27 -0700 Message-ID: Subject: Re: git: cf25897f304e - main - lang/go119: Update to 1.19.5 To: Dmitri Goutnik Cc: 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="000000000000f88cd005f2032a49" X-Rspamd-Queue-Id: 4NsfxD3xS1z3k6s 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 --000000000000f88cd005f2032a49 Content-Type: text/plain; charset="UTF-8" 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 -- Adam Weinberger adamw@adamw.org https://www.adamw.org --000000000000f88cd005f2032a49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 11, 2023 at 1:44 PM Dmitri= Goutnik <dg@syrec.org> wrote:
On 11/01/2023 13:1= 3, 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 changes. Giv= en that
>> all go binaries are statically linked from the go stdlib, upgradin= g 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 that what i= s
> 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 install the sa= me
> package after the next build they will have different package. And if<= br> > 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 <= br> 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 slipper= y slope and it's not just hypothetical.

Less than an hour ago, I email= ed 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, w= here n is defined in go.mk/rust.mk/etc= . It'd be a monotonically-increasing number, where pkg gives it hig= her precedence than PORTREVISION. Anything using USES=3Dgo/rust/etc. would = pick it up.

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

I have a tendency to dre= am up over-engineered solutions without a problem, but I think this is a pr= oblem that actually needs solving. I'm curious what you all think.
<= /div>
# Adam


--
--000000000000f88cd005f2032a49--