From nobody Thu Jan 12 08:06:52 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 4NsxwG4S46z2sdMV; Thu, 12 Jan 2023 08:06:54 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4NsxwG3tgDz3rjx; Thu, 12 Jan 2023 08:06:54 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1673510814; 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=I43NIpYfhpeKtvG9H3cPt86LcLG+k+AGMft5rbwvR00=; b=pquXjvgV7Mw+OurKZ1Q1/64oeGgZPnfLpuFKLICTzhS76k4eZKwHUEzBlxxfA7SOhuKz4X J20loKGTyqIhZPdaokt8Fuz5/lCFTO1lc1VRfZYUGa5hk7AQ7dez7qnAckNEKMM5aQapgO KBdPGjpbv42KgetfmbTr/Fg1cRMPCSVt5YWwg+r2D00x1AArvmjMUMoliOAxerEJl4PAPt loVKT/cuICkm4OG3/MWXOv3qVIN3GreBXYaMm3qqNp3LX1Fs27PxZw3BFSSBCqcVUQ2FV5 fG4Fy7Ss3cIXqZDsEyl1SyX/j74bJiwlGbZn4vi4TFimTCV2ndhp8RMEQKpphA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1673510814; 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=I43NIpYfhpeKtvG9H3cPt86LcLG+k+AGMft5rbwvR00=; b=n4sGBDR97uRT4+VrCz5jbvEDunD309lKBLF7JgjVewgOLShoj/3IUm1NdW4MfT6g5BW2/E 6hFu+5Zp96stQQOMMuSGW9T1OPs2Q8Rui+YOYJUEcbDV+D4COqD3gsJ7Lpu117cg4DPx+A 72yzNNcRlblQUPy9RCStOXbDx1muF8Xh1nBD0Kr5RzpmqpuD+7H/pcRDrcvbwwgNRmUb2N ic3M8J8S0yADsZ/1DnvRJ7nBo91TUT8O2Oto8RkTIwOSerNNXA9Y+bCYMiylT9DigMsdkF IjHE6nMsDzJ6QvDr+SqBCMvEq+6kYv1eupEt7Lzl4Doxyk5mR1spwSiZA8d4kg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1673510814; a=rsa-sha256; cv=none; b=qqcPC/WwdOTug3WNECLRLuR/3i1nNbn/V+2SfSE974V6sEiZCwBf3Y6ZeYEq1nvwA0O5OE UewJXrSsrefAvk8tpo8fqf5ZQRGLnJZFygLpszULZGfLnE89dbJlvioPvUpR/R4mfibf5V dwmWSA6ueIvTv2a5nnJpy8fyQlDmbKZS21O8Qs8cQrpgza18ZJ3e4biX8ay0/bddsvTthy U+fstgmduoMvSIYdYDF9Ii3xODP88EkaWl5OX8do22nP98NEI6zMRHmX3nFPoV6Bta/usq XIsm6Zy/PcorlAoPZbfqcH1jWT+dZUl4HyYe5WOiNNB8D1TukRqtjMO27UcBIg== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NsxwG1r8zzm5h; Thu, 12 Jan 2023 08:06:54 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 9E4B4A6F97; Thu, 12 Jan 2023 09:06:52 +0100 (CET) Date: Thu, 12 Jan 2023 09:06:52 +0100 From: Baptiste Daroussin To: Adam Weinberger Cc: 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: <20230112080652.e5lzd7m727oabgdp@aniel.nours.eu> References: <202301111401.30BE1eAN069454@gitrepo.freebsd.org> <8a2d2724-75f5-ec2a-41af-5b353acb3aa0@syrec.org> <20230111191326.226f0b0346f61136055e62fa@bidouilliste.com> <7bed3cdc-a3f2-a768-e6ab-355b524f9ea2@syrec.org> 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N 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? - 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