From nobody Sun Feb 18 14:23:36 2024 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 4Td7FW4QDdz59p04 for ; Sun, 18 Feb 2024 14:23:43 +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 4Td7FT1d82z4vYg for ; Sun, 18 Feb 2024 14:23:41 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp designates 153.125.133.21 as permitted sender) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=none Received: from kalamity.joker.local (123-1-91-49.area1b.commufa.jp [123.1.91.49]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 41IENaM3046269 for ; Sun, 18 Feb 2024 23:23:36 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 18 Feb 2024 23:23:36 +0900 From: Tomoaki AOKI To: ports@freebsd.org Subject: Re: FreeBSD ports community is broken Message-Id: <20240218232336.6a0b6d2a952539aef9d5ebed@dec.sakura.ne.jp> In-Reply-To: References: <20240218015843.34c5d078@rimwks.local> <7q6ep7m2eee6yqtxftlwkhuwdkssd74vjow55txms7lkokazfu@grrqllhefges> <20240218174921.a8082649142dd43a469bebfa@dec.sakura.ne.jp> <4ekno7iwxvdlw4xeholcrxuuazmcstxkqyidrz27ni43lzu6wg@3ro6r5b2vhoi> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.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=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Td7FT1d82z4vYg X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.58 / 15.00]; NEURAL_HAM_SHORT(-0.99)[-0.993]; NEURAL_HAM_MEDIUM(-0.97)[-0.972]; NEURAL_HAM_LONG(-0.91)[-0.913]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:153.125.133.16/28]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; HAS_ORG_HEADER(0.00)[]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; DMARC_NA(0.00)[sakura.ne.jp]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[ports@freebsd.org]; FROM_HAS_DN(0.00)[] On Sun, 18 Feb 2024 06:47:25 -0500 Aryeh Friedman wrote: > On Sun, Feb 18, 2024 at 6:45 AM Gleb Popov wrote: > > > > On Sun, Feb 18, 2024 at 2:35 PM Aryeh Friedman wrote: > > > No it is not possible since the pkg's are usually of a different > > > version then what is built from ports (ports is almost newer) > > > > There can't be any other way - ports are building recipes for > > packages. Packages will always lag behind. > > > > > may or may not work if your port expects the latest versions. In > > > case you have tried it, is it almost impossible to keep a hybrid > > > pkg/ports machine working your forced to pick one or the other and if > > > your maintainer then your forced into ports only. > > > > If you're using ports only then you still compile everything. I fail > > to see how this is Poudriere's fault. > > It is Poudriere fault because the default config is completely in > appropriate for anything smaller then a great builder in the sky > machine (aka mere mortals). The defaults for portmaster and make > install work very well on all machines though. Adding option "-S" for poudriere significantly reduces build time, at the cost of risks of possible insanity. When any port which is required by some ports and forces its consumers to be rebuilt after upgrading is upgraded, if all (including optional) consumers are bumped, there's no difference. But if any of consumers are not bumped, it would NOT be rebuilt with "-S" option, while without "-S" forces all consumers to be rebuilt regardless they are bumped or not. But if lang/rust[-devel] and/or relatively heavy consumers are upgraded, it wouldn't help. With my experience, rustc EATS UP ALL CORES INCLUDING HTT CORES EXISTINGG and the computer becomes unresponsive. -- Tomoaki AOKI