Date: Tue, 19 Apr 2016 08:54:48 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Julian Elischer <julian@freebsd.org> Cc: Alfred Perlstein <alfred@freebsd.org>, 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: <E35E67E4-2088-46D6-A4BE-173475AF4C9E@FreeBSD.org> In-Reply-To: <5715E1E9.8060507@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19 Apr 2016, at 08:44, Julian Elischer <julian@freebsd.org> wrote: >=20 >> 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=E2=80=99s 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=E2=80=99s very hard to tell = which subsets of the packages people want. That=E2=80=99s exactly the = situation that we=E2=80=99re in now: we know some people don=E2=80=99t = want docs or games, but that=E2=80=99s about all that we know. It=E2=80=99= s easy to move to a model where we have *fewer* packages in the future, = but it=E2=80=99s harder to split them. That also applies to = dependencies. If I know that a port depends on the shell, then it=E2=80=99= s easy to update it from depending on a sh package to depending on a = core system utilities package automatically, but it=E2=80=99s 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?E35E67E4-2088-46D6-A4BE-173475AF4C9E>