From nobody Thu Jan 12 09:11:03 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 4NszLR2M9Wz2p3kR; Thu, 12 Jan 2023 09:11:11 +0000 (UTC) (envelope-from mat@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NszLR1wHXz40FD; Thu, 12 Jan 2023 09:11:11 +0000 (UTC) (envelope-from mat@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1673514671; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1/hKpHMTeSh4TZkXOMZar4yIRai1vDzSuQDo+XPuXPQ=; b=C/BY1J4MkXy7IIKqutz59Rwx+xYnvpR3Gbq/mex7bOGPsJaayayAAVzoYxL5rIpleYYExA V3MmM6Mt2HfF6A0vFgSit6/SAhovxlsa41R4wqK6fEOibJRygo3qJB70fhRKE+ONDQxI1n 80TNOvZl3IoUevmHy7FMIDP5wgz8jq6n7HlrV68j8nd9sfDyRlDvzSeIzHj/c0abFX9GWG xn743cRNpxLBXBUQIUHOrVSQE8GiYk5WwqR3sdGXBC1V/RtBVcBPckN5oMUhZapdR649ak CW2cVLcnzC/Ntdvje9Az45MyuR21iBZKqHdoImeKJqW7iWrMFlTtFCIbjVZJXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1673514671; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1/hKpHMTeSh4TZkXOMZar4yIRai1vDzSuQDo+XPuXPQ=; b=oUSC1eO0fsHnML+cy1Mi+FkMkifQpjbX9BHfgf4sDEZdhAhDjITdzS+o2HuaEsOe9f79P1 yc4GHDhFQYqg4YVtU0xATxX3jmLMlQBsEl0Sli1R0hoZhxOLN0lNnlXH3dSsw6c31Xsbnf eIbz6mBalBDaU4Ol/yBZ9fN3CJh0+Ffwg+J3YAEFlGPzgQbBV7Q7PmaLc5bIK9jvyhp5Ug UijUyt5/tFhV6Up6xETIGirKQhDkVGjRGEb0P3JtMocIfE6Z9/Ws9X4pYb48EKI9l6UC6v 2N7yjC1NrAUEX51XpnLjqvlwWZqE6Ten5KNaprAaEZ4qgYGMDEVehWQdxNNMxw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1673514671; a=rsa-sha256; cv=none; b=ERLLAkL4+8yTYp/qCuO536bcNoRc8NHrmmhTazk3A6oz5AiTXfVOykvBvwGe4fXXJR2B9u XYOOzp3hd1X/YftRhyKVyOY5T4oY/Q2K4FpIfF1ehatR1bQiM19/DObNERLnKqkRVLG/Fw dQeuBIZ/hOLBPLSbwYIZXxLpyKQhsygpRPwHFmWd99hpCZxf984XduBOGtPA8E66XjMKAF BCVOQDYFsO/XLguuuGp64tHnfqc6ESb/w1QoFz28vzP9xxTy5R15f0gH8vcjPK8gWz98za EL2BuUY0KJ/vKTXsr7k35GcV6J9p+5Mk9ADcn1PMTg3kEcJQxTE1R2T044GU9g== Received: from mail.j.mat.cc (owncloud.cube.mat.cc [79.143.240.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.mat.cc", Issuer "R3" (verified OK)) (Authenticated sender: mat/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NszLQ6ntGzn5T; Thu, 12 Jan 2023 09:11:10 +0000 (UTC) (envelope-from mat@freebsd.org) Received: from aching.in.mat.cc (unknown [IPv6:2a01:e0a:836:f670:611c:6fed:d46c:eaa7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: mat@mat.cc) by mail.j.mat.cc (Postfix) with ESMTPSA id 41D6A942D80; Thu, 12 Jan 2023 09:11:08 +0000 (UTC) Date: Thu, 12 Jan 2023 10:11:03 +0100 From: Mathieu Arnold To: Baptiste Daroussin Cc: Adam Weinberger , Dmitri Goutnik , Emmanuel Vadot , Dmitri Goutnik , ports-committers@freebsd.org, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org Subject: Re: git: cf25897f304e - main - lang/go119: Update to 1.19.5 Message-ID: <20230112091103.svidii75ueev4xfx@aching.in.mat.cc> 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> 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 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4uxnwfm37hj6qjou" Content-Disposition: inline In-Reply-To: <20230112080652.e5lzd7m727oabgdp@aniel.nours.eu> X-ThisMailContainsUnwantedMimeParts: N --4uxnwfm37hj6qjou Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 wrote: > >=20 > > > 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. 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. > > > > 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 wha= t is > > > > currently in the package repo (official or not). > > > > Also since the builder always bulk -c (I think) this means that i= f 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. > > > > >=20 > > It absolutely is a slippery slope and it's not just hypothetical. > >=20 > > Less than an hour ago, I emailed portmgr about adding a simple and cent= ral > > 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=3Dgo/rust/etc. would = pick > > it up. > >=20 > > 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. > >=20 > > I have a tendency to dream up over-engineered solutions without a probl= em, > > but I think this is a problem that actually needs solving. I'm curious = what > > you all think. > >=20 > > # Adam >=20 > 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) >=20 > 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 real= ly want > that? >=20 > It is also incomplete to solve the "hell" of those kind of packages: >=20 > If we are to really chase properly the packaging of those packages we sho= uld > also track any changes of any of the dependencies which end up bundled (c= rates, > go modules, etc.) in the final packages, to make sure we also bump the re= vision > as soon as any of them is has a security issue for example. how do we fla= g this > change (locally PORTREVISION? globally yetanotheradditiontotheversionnumb= er?). >=20 > This is the level of thinking I think we should have for this type of pac= kages. >=20 > 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. --=20 Mathieu Arnold --4uxnwfm37hj6qjou Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQITBAABCgB9FiEE9XJBpJetWizkEBUef2IOCp6dQb4FAmO/zqdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY1 NzI0MUE0OTdBRDVBMkNFNDEwMTUxRTdGNjIwRTBBOUU5RDQxQkUACgkQf2IOCp6d Qb6RYAv/WgZc/Susd0U/nTfu0vQytxYPekjM1lm/fUcPbRCRKDP6e5zq/58nPNp5 FAoWTi+LIbJ1cNzHxl4FdYLhcxZcqSidzuWXx/pvbI5MQYIoKLbxHBaLZpVH73RI yHEsi5lHP3/pdDJOgZm/ucBTlQDUc9Jo3ssBEB5bU91zNUF9z3YE6ShsBpLy+HCD /OZWnZGLurR8+O0dCbMAFI3CS+2fuuz3BBbs/8INyJ4lyyrmSxEW34zeyF7JhFM5 wg40LALw/VYtUa62zHgpRXrnhyCUIbEATRt4DqxS7flhQGEhMJBrvH8b2I1TqpIW n7EHEBILTFtah+HZkPqEVV2eriGtd7ezdt4e+O2JLaY1QwZh9AjPd7p4roRaq/VQ sLsBSW8CqIZEVo0wxOLAC3ioe8Zy/tNGJuHq9NTE+85UzbAuaKjWUEtQw5WaGCDS DKX/EyhYUfA04dTs1UKOOrhLy/AjJ8UP+59uCrssbU6VoyxIaSPJV9VB3uajwZ1f MxHcgT5e =gOC2 -----END PGP SIGNATURE----- --4uxnwfm37hj6qjou--