Date: Sat, 4 Jun 2016 11:46:24 -0700 From: Jeffrey Bouquet <jeffreybouquet@yahoo.com> To: Franco Fichtner <franco@lastsummer.de>, Miroslav Lachman <000.fbsd@quip.cz> Cc: freebsd-ports@freebsd.org, Torsten Zuehlsdorff <mailinglists@toco-domains.de>, Vincent Hoffman-Kazlauskas <vince@unsane.co.uk> Subject: Re: old ports/packages Message-ID: <12b50783-f79b-56b6-25f8-91e23a902776@yahoo.com> In-Reply-To: <9D785F08-AB0B-4324-B1B3-286D90AF9BF7@lastsummer.de> 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> <9D785F08-AB0B-4324-B1B3-286D90AF9BF7@lastsummer.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/ 3/16 08:17 AM, Franco Fichtner wrote: > Hi there, > >> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.fbsd@quip.cz> wrote: >> >> 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. >> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.fbsd@quip.cz> wrote: >> >> 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=203630 > [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 > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" I again wonder whether the old /var/db/pkg [ flat files rather than an ABI ] could serve as a secondary means to the pkg upgrade of port/packages that was problematic [above], reverse engineered back into place with say, portmanager [deprecated] and portupgrade and portmanager, so that if machines in production fail some way due to pkg, the older way would suffice for awhile, and on such machines in production, each upgrade would entail both methods, and in case the preferred one fails, somewhat like HAST or ZFS or Carp, the backup methodology to keep the services up after downtime could strengthen the case for FreeBSD vs other OS which only use a singular method, I know if I were much younger I'd set about learning C again and proceeding apace... all else being more favorable than is usually the case, of course, unless I thought of some easier way than /var/db/pkg once having learned sqlite3, of which I remain unlearned.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12b50783-f79b-56b6-25f8-91e23a902776>