From nobody Thu May 22 21:14:29 2025 X-Original-To: freebsd-current@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 4b3Ldq5pmTz5vx9B for ; Thu, 22 May 2025 21:14:39 +0000 (UTC) (envelope-from resin-freebsd@g-cipher.net) Received: from g-cipher.net (leon.g-cipher.net [5.9.120.19]) (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 4b3Ldp2JpSz3vd2 for ; Thu, 22 May 2025 21:14:38 +0000 (UTC) (envelope-from resin-freebsd@g-cipher.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of resin-freebsd@g-cipher.net designates 5.9.120.19 as permitted sender) smtp.mailfrom=resin-freebsd@g-cipher.net; dmarc=none Received: (qmail 68652 invoked from network); 22 May 2025 16:14:32 -0500 Received: from unknown (HELO ?192.168.7.176?) (resin@unknown) by g-cipher.net with ESMTPS (TLS_AES_128_GCM_SHA256 encrypted); 22 May 2025 16:14:32 -0500 Message-ID: <08e9057e-d741-49a8-a93d-7947f79179d3@g-cipher.net> Date: Thu, 22 May 2025 14:14:29 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Updating build and jail manual pages to include missing or obscure information To: freebsd-current , doc References: <2d6ef406-2a4e-4876-b784-e9ad5a0e11be@app.fastmail.com> <2f6b255b-696c-44ed-9c32-b70daec0ff4f@g-cipher.net> Content-Language: en-US Cc: Alexander Ziaee , Dave Cottlehuber , emaste From: Billiam Crashkopf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4b3Ldp2JpSz3vd2 X-Spamd-Bar: / X-Spamd-Result: default: False [0.26 / 15.00]; NEURAL_SPAM_LONG(0.94)[0.941]; NEURAL_HAM_SHORT(-0.94)[-0.937]; NEURAL_SPAM_MEDIUM(0.35)[0.354]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+a:c]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:5.9.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[g-cipher.net]; TO_DN_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] On 5/22/25 12:27, Lexi Winter wrote: > resin-freebsd@g-cipher.net: >> Just to share my two cents: I think all available options should be >> documented in the manual. > i'm fine with having 'make world' documented somewhere, although such > documentation should probably note that it's been deprecated for over > 20 years. i'm just saying it can't be documented as a way of upgrading > the host system since it won't do that -- it will refuse to run unless > DESTDIR is set, so it can upgrade jails, but not hosts. Totally fair. I'm still unclear on the deprecated status of the 'world' target.  Is it deprecated because it's dangerous for the running system?  It clearly has some guard rails to prevent accidents (DESTDIR or HISTORICAL_MAKE_WORLD must be set).  If it's truly deprecated then it shouldn't be used in the jail instructions. But it also has more functionality than buildworld + installworld because it has logic for optionally making pre-world and post-world targets. Options I see are:   * Declare the 'world' target deprecated only for updating, but fine for other uses   * Declare the 'world' target deprecated for all uses; update the jail build instructions with a more verbose invocation.   * Declare the 'world' target deprecated for all uses; add an alias for the same recipe that doesn't have any legacy meaning.