On 8 Mar 2016, at 15:14, Slawa Olhovchenkov <s...@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). 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. 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. 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. David _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
