Re: [CFT] packaging the base system with pkg(8)

On Tue, Mar 08, 2016 at 05:35:59PM +0000, David Chisnall wrote:

> On 8 Mar 2016, at 15:14, Slawa Olhovchenkov <slw_at_zxy.spb.ru> wrote:
> > 
> > Yes, I undertund this. But what profit of this? Addtional size is
> > small, many small packages is bad. We already have expirense with
> > spliting Xorg to many small packages -- no profit of this.
> 
> The X.org case is similar, but not quite the same.  The X.org split
> was to ease development, but came at a cost of packaging because you
> almost always want all of X (or, at least, most of it - there are a
> few things such as Xephyr that many users may want to skip).

IMHO, for FreeBSD is same. Except embeded systems. But for embeded
systems, after custom kernel and cut off clang next cut off is pkg:
10MB install size and 50MB database size:

% pkg query -a "%n %sb" | grep pkg
pkg 11113058

% ls -lh /var/db/pkg/
total 29707
-rw-r--r--  1 root  wheel   246B Mar  4 22:25 FreeBSD-base.meta
-rw-r--r--  1 root  wheel   246B Mar  4 22:26 FreeBSD.meta
-rw-r--r--  1 root  wheel   5.0M Mar  4 22:28 local.sqlite
-rw-r--r--  1 root  wheel   811K Mar  4 22:25 repo-FreeBSD-base.sqlite
-rw-r--r--  1 root  wheel    43M Mar  4 22:26 repo-FreeBSD.sqlite
-r--r--r--  1 root  wheel   4.0M Mar  7 03:46 vuln.xml

> In FreeBSD, we *do* have a compelling case for installing a small
> subset of the base system: service jails (or ‘containerised
> applications’ as the kids are calling them).  We want to be able to
> install, for example, owncloud and nginx or ejabberd in a jail with
> only the bare minimum required for them to start and run.  We want
> updates to these jails to be fast and we want disk usage (and
> install time) to be low.  In such a jail, I want a shell, the parts
> of sbin needed to do network setup, the libraries that these ports
> depend on, *and nothing else*.  We’re still a way away from doing
> that.

>From one side, you don't need network setup in jail at all: all
network setup can be done by external tools. You also can absent shell
and manage jail as subdir. 

>From other side, detaching jail to other admin and managing it inside
you need many tools for processing logs, network startup script used
cut, sed, dd and any random (at current point) stuff. I am don't see
correct depends for startup scripts now and this is to complex work. 

>From thrid side, using ZFS and cloning can eliminate overhead of
duplicating.

> Comparing the installed sets can be simplified with some
> improvements to the pkg UI, for example allowing a set of packages
> to be aggregated into a single entry.  This is not quite the same as
> the metapackage concept.  If you install everything, then a
> FreeBSD-base-all metapackage might show up as a single thing unless
> you ask for a verbose output.  We can also present these in a
> hierarchical manner, so that you can drill down and see more detail
> if you want to.

Next problem is:

1. install some packages.
2. adding missed packages to FreeBSD-base-all
3. Don't see FreeBSD-base-all, but see 750 separated packages

Or:

1. install FreeBSD-base-all
2. remove some packages
3. What I see?

> In terms of comparing packages, if you’re doing that visually then
> you are likely to have problems anyway, unless your eyes and brain
> work far better than most humans.  We can make that much easier by
> providing libxo output in pkg and allowing you to have a simple jq
> script that tells you what the differences are.

In case of 500-1000 packages -- yes, you right.
In case of 5-10 base packages -- eyes is enought.
I am don't need to have utility to comparing and sepeartely installed
reference system for discovering problematic system.
Less separeted packages, more unification in all installed system --
easy to support for me and on any forum for newbies.