On 06/ 3/16 08:17 AM, Franco Fichtner wrote:
> Hi there,
>
>> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.f...@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.f...@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-unsubscr...@freebsd.org"
Yahoo mail refused to send my full reply to the recipients. Suffice to
say I
recommended a backup to the pkg problem by a secondary
/var/db/pkg concurrent methodology. Sorry to be so terse.
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
