From nobody Thu Feb 16 08:56:08 2023 X-Original-To: ports@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 4PHTM30yGVz3ptQs for ; Thu, 16 Feb 2023 08:56:15 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4PHTM10KrPz3msW for ; Thu, 16 Feb 2023 08:56:12 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 31G8u8V9020589 for ; Thu, 16 Feb 2023 17:56:09 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 16 Feb 2023 17:56:08 +0900 From: Tomoaki AOKI To: ports@freebsd.org Subject: Re: How poudriere's PACKAGE_FETCH_WHITELIST should work? Message-Id: <20230216175608.c4d5bb2810447fa7241237f6@dec.sakura.ne.jp> In-Reply-To: References: <9B296C55-6F06-4E10-9056-ECAD05630920.ref@yahoo.com> <9B296C55-6F06-4E10-9056-ECAD05630920@yahoo.com> <287633b4-1363-4d91-a572-bc0960f592e5@quip.cz> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-0.60 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[ports@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; HAS_ORG_HEADER(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4PHTM10KrPz3msW X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N On Wed, 15 Feb 2023 18:10:10 -0800 Mark Millard wrote: > On Feb 15, 2023, at 17:22, Tatsuki Makino wrote: > > > I was introduced to this feature in a reply to an email titled "[through-able] poudriere: I don't want to rebuild rust with PORTREVISION bump of curl" that I wrote on or about 2023-01-20. > > > > This still means that the dependencies held in the package must match up to the version number to be used, right? > > As I wrote in that e-mail, the dependent packages can be checked with the following command, which poudriere also seems to use. > > pkg query -F somewhere/llvm10-10.0.1_10.pkg '%do %dn-%dv' > > > > In the current porttree, python39 is 3.9.16_1. If this package has already been created locally, it would seem that the llvm* package that depends on python39-3.9.16 or earlier would not be used when fetched, is that correct? > > > > # note that I avoided recreating llvm13 and llvm15 that way :) > > > > Turns out my notes did not apply: the person I replied to was > using quarterly and so things were apparently not changing. > > But I'd not checked the transitive closures for the various > ports involved for the 2023Q1 context. Using rust and its > curl dependency as an example: > > curl in turn depends on at least devel/pkgconf , lang/perl5.32 , > security/ca_root_nss , www/libnghttp2 , security/libssh2 , > and dns/libpsl . So there is a fair list of things that can > cause curl to rebuild, which in turn leads to rust potentially > rebuilding, even if the rebuild result for rust ends up not > being installed for lack of a version bump: existing install > is still expected to be compatible given the lack of a version > bump. > > The way rebuilds happen is that an update to the likes of, > say, security/libssh2 deletes the old package. Then curl's > package is deleted because of the lack of a package for > security/libssh2 . (This is before security/libssh2 or > anything is rebuilt.) Then rust for similar reasons. Deleting > the packages does not delete the installs (important later). > Then the deleted packages are rebuilt so that they are > available to future pkg commands, even if it turns out that > some of the installed ones would not be updated by the likes > of a "pkg upgrade" in the same time frame (version numbering). And poudriere (at least ports-mgmt/poudriere) sometimes fails trying to use "recorded as existing, but deleted for rebuild" pkgs, at least -S option is set. These usually are finally succeeds on next or after following several runs. Does this annoyance fixed on ports-mgmt/poudriere-devel? > > Again, I've not gone looking for changes in the transitive > closure of the dependencies. I'm just noting some of the > general structure. I've not checked if this explains all the > specifics that happened. > > Going in the other direction, there may be more that is > involved than I know about. But I've observed the delete > sequences and later rebuild sequences that do not lead > to updated installs of various things rebuilt. (A lot over > the years.) > > === > Mark Millard > marklmi at yahoo.com > > > -- Tomoaki AOKI