From owner-svn-src-stable@freebsd.org Tue Apr 10 06:57:07 2018 Return-Path: Delivered-To: svn-src-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 552DCF821BA; Tue, 10 Apr 2018 06:57:07 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from mail.daemonic.se (mail.daemonic.se [176.58.89.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB4FE71855; Tue, 10 Apr 2018 06:57:06 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 40Kydr2lynzDhHq; Tue, 10 Apr 2018 06:57:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=daemonic.se; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject:received :received; s=20151023; t=1523343423; bh=iNrI/OSAJSpIEv3gK06oGAq0 nfftQzeNb9W5ui1JO50=; b=ObxJlAbBB0z5BZF0MClLYI+iRRe/9X3bDRR3vaHN au3CQO7AaHVgT4EoKXCVWKWU4i7/HUCkbTpXGuOZKyxBXScqnkx1KOSqgZyiyFki PLB4ZyvNXEmrztJscNRF7gcc7RJyZrbqEIpbMCQZbfDHKi+LaWX6vKaOMuBYBU5g mlk= X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([IPv6:::1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [IPv6:::1]) (amavisd-new, port 10587) with ESMTPS id p-FRygrG-u5T; Tue, 10 Apr 2018 06:57:03 +0000 (UTC) Received: from garnet.daemonic.se (host-90-232-228-250.mobileonline.telia.com [90.232.228.250]) by mail.daemonic.se (Postfix) with ESMTPSA id 40Kydq0gdxzDh2K; Tue, 10 Apr 2018 06:57:03 +0000 (UTC) Subject: Re: svn commit: r331880 - stable/11/etc To: Kyle Evans , Warner Losh Cc: "Rodney W. Grimes" , svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers , svn-src-stable-11@freebsd.org References: <201804091552.w39Fqv2S019416@pdx.rh.CN85.dnsmgr.net> From: Niclas Zeising Message-ID: <6928b703-536e-b1a7-2a80-6796db15affc@daemonic.se> Date: Tue, 10 Apr 2018 08:56:44 +0200 User-Agent: Mutt/1.5.21 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 06:57:07 -0000 On 04/10/18 04:28, Kyle Evans wrote: > On Mon, Apr 9, 2018 at 11:59 AM, Warner Losh wrote: >> >> >> On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans wrote: >>> >>> Right- so, back out this MFC (and the subsequent FreeBSD_version bump) >>> and fix the ports to do the right thing for 12.x while that's still >>> not a technically supported branch? >> >> >> Don't back out the version bump. Other things may be riding along on it 'for >> free'. Better to bump it again when you unMFC (if it's been more than a few >> days since we've had one), and then yet-again when a fixed MFC happens. >> Unless there's something you can ride along on for free :) >> >> Otherwise, that's a great plan. > > Ok, I think the result of this thread and discussion with 0mp is the > following set of actions: > > 1.) One (1) commit to stable/11 to revert the MFC and bump > FreeBSD_Version again for the removal > 2.) One (1) commit to doc to document the new FreeBSD_Version > 3.) Fixing ports to use the "new" behavior on 12, both the > yet-to-be-patched ports and the ports that had already been patched > under the assumption that it would still land first in 11.1-stable > 4.) Documenting the original commit? > > The hard part of point #3 has already been done by 0mp, who has > submitted patches for all of the ports using this behavior. His > patches will just need a bump of the version they're testing to the > 12.x FreeBSD_Version and a fix-up on the patches that already landed. > > For point #4, this seems like the type of breakage we should be > documenting in release notes or something for the eventual upgrading > of systems to 12.0. All usage of _limits stuff in custom rc scripts > need to be audited, and all rc.conf(5)'s need to be scrubbed for > ${name}_limits usage that doesn't make sense with the new context. I'm > not sure what the most appropriate action here is, or what we should > do this far ahead of time for such a thing. > > If this sounds like a good path forward, I'll execute #1 and #2 in the > morning (CST, so ~11 hours from this e-mail being sent). > This still doesn't fix the issue of some early start up scripts depending on stuff that's not available yet, when for instance /usr is on a separate FS (which was the normal way to set up a system way back when). This issue was first noticed more than 2 years ago, so someone did notice the breakage. It just hasn't been fixed for an entire release cycle. Regards -- Niclas