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

On Tue, Apr 19, 2016 at 08:54:48AM +0100, David Chisnall wrote:

> 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.

Not true. For very small system pkg overhead too high and comparable
with size of base. NanoBSD anyway don't updated and build by pkg, only
by slice swap.

> 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.

Too hard to work. nginx+ngx_lua need additional libraries, ngx_lua
don't show additional dependeses, ports infrastructure don't tests
this dependeses....

> 
> 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.

This is too teoretical. In pratical pepole don't want to waste for
select from huge list of strange packaes. Also, systems may live after
install and managed by different person. This person don't be grateful
for docs and manuals absense.

Writing docs and HOWTOS will be harder too: for every line you must be
write "install package foo", "install package bar"...