Date: Fri, 3 Jun 2016 17:17:57 +0200 From: Franco Fichtner <franco@lastsummer.de> To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Torsten Zuehlsdorff <mailinglists@toco-domains.de>, Vincent Hoffman-Kazlauskas <vince@unsane.co.uk>, freebsd-ports@freebsd.org Subject: Re: old ports/packages Message-ID: <9D785F08-AB0B-4324-B1B3-286D90AF9BF7@lastsummer.de> In-Reply-To: <574ED144.1050603@quip.cz> References: <03cc4012-026e-c007-09e1-ee45524f1b95@elischer.org> <B32DD056A6281C191CD35AA2@ogg.in.absolight.net> <c528a76d-5b94-01a3-f27e-7d174faf544e@freebsd.org> <1FAFDF989841D03604BB448B@atuin.in.mat.cc> <7b8d22c6-1fed-d517-9f89-693b88dfc358@freebsd.org> <20160504070341.GV740@mail0.byshenk.net> <3dfd6fea-da32-b922-65d1-f64b8e113112@toco-domains.de> <6e340f95-6d10-4991-0cd6-95d336e2f044@gjunka.com> <3e55c7d8-801c-a2b3-e92e-9945e896142b@toco-domains.de> <5809f808-8b16-93ed-5351-828a7d68eb2b@unsane.co.uk> <c71c19de-f712-6116-cdb3-10580054ab23@toco-domains.de> <574ED144.1050603@quip.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi there, > On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.fbsd@quip.cz> wrote: >=20 > There is a main difference - if you upgraded from 9.2 to 9.3, you = don't need to recompile (reinstall) all ports, but if you upgraded from = 9.3 to 10.x you need to reinstall all your packages and then remove old = 9.x libraries from the base system. >=20 > On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.fbsd@quip.cz> wrote: >=20 > There is a main difference - if you upgraded from 9.2 to 9.3, you = don't need to recompile (reinstall) all ports, but if you upgraded from = 9.3 to 10.x you need to reinstall all your packages and then remove old = 9.x libraries from the base system. This is very much true for a single user point of view, but the devil is in the details. Let's go through the transition that we as the OPNsense project went through in the FreeBSD 10 series... Not a rant, just facts. The initial release was 10.0, which was phased out after a year, leaving us no choice but to go 10.1 just two months after our initial release in order to receive official security updates. Worst case it takes a few months to adapt to the major transition so that's 12 months minus X months of internal engineering, depending on your staff expertise. In that case we started in 2014, took us 4 months, that's 6 months including the time 10.0 was officially available, so 6 months left for support, when you actually start adapting to 10 as soon as it comes out. For many that's a luxury not going to happen. One can blame anyone for starting late, but it's not going to solve the real world problem. 10.1 went really well. When 10.2 happened for us in January 2016, however, we've already went testing 3 months before and had a number of issues that were not being addressed upstream for a longer amount of time: o HyperV disks stopped registering as ada(4) devices, killing installs that were not using labels. Never fixed. o Hyper-V NAT broken for a very long time, only fixed in 10.2 after active polling for an errata[1] o pf checksumming broke with offloading[2] But the kicker was that building pkg on 10.2 suddenly changed the ABI behaviour in at least two ways that we know of: (1) The reaper for package scripts was now suddenly active, making it a lot harder to restart a service on package upgrade from their own scripts. We hat do investigate and disable the reaper code in pkg itself in order to retain functionality. I would think that others ran into this silently as well. (2) 10.1 systems preloading the "new" pkg for 10.2 were unable to upgrade certain packages, in this instance isc-dhcp43-*. It took a few months to even get to the point of triggering this. In short, we pinned down the pkg ABI to 10.1[3] in order to allow our older 10.1 systems to upgrade. This should not be happening in a "ABI stable" environment. There is pkg-static, but at least in the scope of FreeBSD it's only used when pkg fails for this or that reason, which is very hard to explain to a GUI or backend script. Why not make it the default? 10.2 was the proverbial rollercoaster ride that some would not like to see repeated. 10.3 looks better, but what does that say about 10.4 or 11.0? But 10.3 already had a major speed regression during package installation only caught after the release[4]. Who knows what our users will be facing once we go live in a few months. For downstream projects, this is at least an order of magnitude worse than the simple user that sits in a shell and runs a magical fix command to amend its upgrade path. fir some it's even impossible to get into a shell. Most of downstream projects have automated processes, upgrade features that rely on certain behaviour, well, rely on behaviour to stay stable for at least 10.x, which would make sense. ;) And now we run for each 10.x, every time just run for it in order to make sure that we're not missing an iteration that would amplify the problems we'll be facing with upgrading later. And mind you, this is *with* rebuilding everything from scratch for each minor update just to be on the safe side. :) Cheers, Franco -- [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203630 [2] https://www.freebsd.org/security/advisories/FreeBSD-EN-16:02.pf.asc [3] https://github.com/opnsense/ports/commit/76975890103 [4] = https://www.freebsd.org/security/advisories/FreeBSD-EN-16:06.libc.asc=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9D785F08-AB0B-4324-B1B3-286D90AF9BF7>