From nobody Thu Jan 12 09:20:18 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 4NszY13t2Fz2p52v; Thu, 12 Jan 2023 09:20:21 +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 4NszY13C25z418V; Thu, 12 Jan 2023 09:20:21 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1673515221; 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=FmxRdA1pSiSg8flC9m76fEojeGqcOVR9/eXBedAESLg=; b=Dlelq4HIAv81XcUSCSbdHO9CF0AVYDfWOL1RCbG4xEa5kxXHCpHsWymrHM3OmdM3kdUqm5 Q4pboLv971vsMa4ITVhXR7vgeSjZCeDOJiQsR5gW7pm8SQ4WwU0uTODjPSs3kmUl4pEzsS T2wvi/rig2tUzlbqkixjJLzI7d8RImeDbP0fOrgQOa/ZrIp3VgwbvhNa23rzm67PUMP7uc x9AScl+hduX99VqEKs3ooak+DQ91hWH3UnvUM07/H/SWMUUDY4zHP3n10OAcgeaZlHgMXk JJ1e33rPLaubtK33gP4crAUlnEYZsx5PDmsfsXZv7WEYXdaqjYLbq1xeSRLcXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1673515221; 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=FmxRdA1pSiSg8flC9m76fEojeGqcOVR9/eXBedAESLg=; b=laEzB3fPSGAxQOU5fVTd/wb2RXc5Gd9hGk4HSNquH7Q8Tr8kmlzS7+FBZUynp7NF3zSkTn F0SYy154yrUKSk3FpJLNqQtew56JuU9JQBDCHrhymgrLpgLk9mjgAiWNmucaPjrO7m9DQR wzlFqAQfm09SK+ujTW5suuyi8RndZdQd60Z6RgbWHX77+rFMKPwmKn592hLbsXzXT1u23U PpmGJlNIxjZRQd8uIBLDLPZiRlDJjku01freyGX5XPGRc6pyDYYSrLU352K3V3Wj/8h6Os 5kJSGak5SKiSeAVOZnkXO7KwEJpALZIrUI/XIpHb/GTs6JeegHhPY92d+w2v/w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1673515221; a=rsa-sha256; cv=none; b=b7gUQ38OaLrqvpm0pJFkUJaWcGiFRe3CS81l7407hilUJrQJSqINK7BJ89QcIsMpbS/aJe JcMabtFcB1rexVKeUcdkiSepmWCbgxBLpqoZ1usr5rwhiF76SEJEVNopfx4ZKrAZ0beHKz bZMG7SxPxtYiCaMbF8JPU7D2TYOJkGVnmpFhr3tL3UB7SHagxmnf+/ZKYCuHTi12JVridZ gUJJXwIme0qZDXdZsiBSJJJIhNzOkdMLYfAJ7E+BNr5B1YVunAApUd2TG2TfxnHKP0+Tff K5Xc9rl9HUXYf5jr09V0xPvgJpWEoEdJtoDzKSNzAhfhjUZQXqgjZXj0eYAR0A== 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) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NszY111xqzlyl; Thu, 12 Jan 2023 09:20:21 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id ABCCDA7200; Thu, 12 Jan 2023 10:20:18 +0100 (CET) Date: Thu, 12 Jan 2023 10:20:18 +0100 From: Baptiste Daroussin To: Mathieu Arnold 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: <20230112092018.atz445nkjg2cgrop@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> <20230112080652.e5lzd7m727oabgdp@aniel.nours.eu> <20230112091103.svidii75ueev4xfx@aching.in.mat.cc> 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: <20230112091103.svidii75ueev4xfx@aching.in.mat.cc> X-ThisMailContainsUnwantedMimeParts: N 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 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. > > 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