Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Apr 2016 19:24:21 -0400
From:      Garrett Wollman <wollman@csail.mit.edu>
To:        David Chisnall <theraven@FreeBSD.org>
Cc:        freebsd-pkgbase@freebsd.org
Subject:   Re: [CFT] packaging the base system with pkg(8)
Message-ID:  <22294.48677.302730.437617@khavrinen.csail.mit.edu>
In-Reply-To: <E35E67E4-2088-46D6-A4BE-173475AF4C9E@FreeBSD.org>
References:  <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715E1E9.8060507@freebsd.org> <E35E67E4-2088-46D6-A4BE-173475AF4C9E@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
<<On Tue, 19 Apr 2016 08:54:48 +0100, David Chisnall <theraven@FreeBSD.org> said:

> I see basically three use cases for a packaged base:

I'd like to add one more:

4) People who have their own custom builds and want to be able to do
automated binary upgrades of the base OS in the same way that they
upgrade other components, across fleets of servers.

Right now it's not very practical to run your own FreeBSD-update
server, and even if you have one, the process of applying these
updates is still insufficiently automatable.

We are not quite there yet with "packaged base", and in my particular
use case, I'd be perfectly happy with one package for the entire OS.
There are still a lot of things that need to happen with pkg in
general to make automatic updates sufficiently reliable -- but being
able to install minor updates with one command is already a huge
improvement over where we are now.  Huge enough, in fact, that I'm
planning on entirely skipping 10.3 and waiting for 11.0 to come out
*just to get this functionality*.

Over the longer term, we need some additional capabilities to get to
where we want to be.  These would be things like:

a) Proper dependency ordering for stopping and starting daemons during
upgrades.

b) Reliably determining which processes need to be restarted after a
security update to a library (or a daemon that isn't started from an
rc script).

c) A general, configurable unattended-upgrade facility, so that we can
just enable one periodic(8) job and be certain of getting security
updates to the base system, reliably, with some indication of when a
pending update requires a reboot that can be inspected by monitoring
systems to raise an alert.

-GAWollman




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22294.48677.302730.437617>