old ports/packages

Fri Jun 3 15:25:18 UTC 2016

Hi there,

> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.fbsd at 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 at 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