From owner-freebsd-stable@freebsd.org Tue Sep 19 08:45:27 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83EB4E0582D for ; Tue, 19 Sep 2017 08:45:27 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4492671A18 for ; Tue, 19 Sep 2017 08:45:26 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from leaf.local (unknown [88.202.132.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 8CB859266 for ; Tue, 19 Sep 2017 08:45:23 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Subject: Re: ABI changes within stable branch To: freebsd-stable@freebsd.org References: <1b07bf49-508a-c6b4-e805-df7d43230f81@ish.com.au> <20170919081532.GB2170@home.opsec.eu> <21c1d954-8bdf-0d16-f1ca-176cd6df7a60@ish.com.au> From: Matthew Seaman Message-ID: Date: Tue, 19 Sep 2017 09:45:22 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <21c1d954-8bdf-0d16-f1ca-176cd6df7a60@ish.com.au> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 08:45:27 -0000 On 19/09/2017 09:32, Aristedes Maniatis wrote: > On 19/9/17 6:15PM, Kurt Jaeger wrote: >> Hi! >> >>> Now that we are on a faster upgrade policy for minor branches, it is expected that we'll upgrade from 11.0 to 11.1 to 11.2 much faster than in the old days. I can cope with that, but it appears that functional changes are also being made within the stable branch as seen here: >>> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221672 >>> >>> A new fdatasync() method is available in 11.1 but not in 11.0 which means that I now need to maintain separate ports trees for each minor update. I've never done this before, assuming (correctly for me until now) that all ports build on the latest minor release within the stable branch would work on older releases until I was ready to upgrade them. >> >> I think it was the other way around: All ports build on the .0 of >> a RELEASE work on all later .x of that RELEASE. Which makes it a bit >> difficult, if a .0 is no longer supported/patched by the secteam. >> >> A pointer to the official policy would be nice 8-} > > Then we have a problem since https://pkg.freebsd.org/freebsd:11:x86:64/latest/All/ has been built on 11.1, not on 11.0 (I just tested it with csync2 which I know fails). Packages there may fail to run on 11.0, but there is no clear indication, just random failures at runtime. > > Maybe we'd need specific 11.0, 11.1, 11.2 releases instead of quarterly releases? Ports are still being built according to the same policy -- on the earliest still-supported release of each major branch. It's just that now, for 11.x and subsequent, 11.0 goes out of support a month or so after 11.1-RELEASE comes out. You're meant to have upgraded by now. The 11.0 -> 11.1 upgrade is intended to be a pretty routine thing that you can do about as freely as you can apply a security patch or other update within the 11.0 series. Yes, there should be some sort of warning about your system being older than what the package was built for. Ideally it would be intelligent enough to understand about things like the new fdatasync meaning libc was incompatible. Once we do finally get base system packages this problem should largely disappear, as the normal pkg(8) dependency handling should pull in an updated libc as a dependnecy of anything expecting the new fdatasync(). Cheers, Matthew