Date: Tue, 19 Apr 2016 07:33:30 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: David Chisnall <theraven@FreeBSD.org>, Julian Elischer <julian@freebsd.org> Cc: lev@FreeBSD.org, Glen Barber <gjb@FreeBSD.org>, Nathan Whitehorn <nwhitehorn@freebsd.org>, Sean Fagan <sef@ixsystems.com>, freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <571641BA.8010205@freebsd.org> 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
It is very important to understand that a packaged base is extremely useful for those building any sort of distro or appliance distro. So although the concept of "user serviceable" is important, it's not just that. Such a change makes it easy for a distro or appliance making to cherry pick updates to the system without having to pull the entire system forward. One of the huge pains about using FreeBSD at my last work was that the base system as a whole was a bit challenging to pry apart so that an incremental update could happen. Let's say I needed a patch to openssl, well that was HARD even for me. My choices were to update the whole system (which broke things), pull in patches and apply them (hard and scary), figure out a way to pull it from ports instead... super hard as "base" built before ports in "nanobsd". Quite frankly I didn't have the time for it. As someone who laid the foundation for an FreeBSD appliance, I wholeheartedly welcome this, it will be HUGE for appliance builders. I am also confident that we will very easily sort out how to make "micropackages" or some such mechanism within at most 3 months after the code lands. The reason why is because I already see some excellent proposals for such mechanisms in this thread. -Alfred On 4/19/16 12:54 AM, David Chisnall wrote: > On 19 Apr 2016, at 08:44, Julian Elischer <julian@freebsd.org> wrote: >>> All this can be done by meta-packages which depend on larger package groups. >> Currently Metapackage is a way to make 10 packages look like 11 packages. The framework needs to understand to hide the 10 internal packages if they are part of a metapackage. > I agree, and patches to do this are very welcome. Currently, pkg is short of contributors. > > I see basically three use cases for a packaged base: > > 1) People wanting a FreeBSD install to use as a server or workstation. These people will install the FreeBSD 11 metapackage and not care that it is a few hundred MBs. It would be nice if the pkg tool could present this as a single package in list views, but that’s a UI issue with pkg, not an issue with the number of packages in the base system. > > 2) People wanting to install embedded systems. Anyone who has tried to run FreeBSD on a system with a small amount of flash storage will have encountered the pain of having to use some kind of ad-hoc update. Being able to manage updates to these systems with the same packaging tool as you manage big systems is a big improvement. > > 3) People wanting to install service jails (sorry, containerised applications). These want the smallest possible attack surface and so want the smallest amount of the base system that they can have. Here, small packages are an advantage. It will take a little while for ports to learn enough about the granularity of the base system for this to really be useful, but it would be great to be able to install nginx, for example, in a jail and have only the handful of libraries that it needs. > > The big advantage of going with small packages initially, however, is that it will allow us to get some data on what the correct groupings are. If we have large packages, then it’s very hard to tell which subsets of the packages people want. That’s exactly the situation that we’re in now: we know some people don’t want docs or games, but that’s about all that we know. It’s easy to move to a model where we have *fewer* packages in the future, but it’s harder to split them. That also applies to dependencies. If I know that a port depends on the shell, then it’s easy to update it from depending on a sh package to depending on a core system utilities package automatically, but it’s very hard to do an automatic update in the other direction. > > David >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?571641BA.8010205>