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

On 20 Apr 2016, at 06:06, Julian Elischer <julian_at_FreeBSD.org> wrote:
> 
> my problem with 400 packages is that is is hard to decide what you are actually running.. or is it FreeBSD 11? is it FreeBSD 10.95342453?
> you have no way to tell exactly what you have without comparing all the packages to a known list.
> uname doesn't mean much, nor does "__FreeBSD_version" if everything comes with its own versions.

I think that it’s very important, for the purpose of a constructive discussion, to separate the two concerns:

1) The number of packages that the base system has.
2) The user interface by which the packages are presented.

I believe (and, please, correct me if I’m wrong), that all of the complaints in this thread have been about the UI, not about the underlying mechanism.  That’s not to say that they’re unimportant (quite the reverse), but that they can be solved concurrently with the task of preparing the base system for distribution in packaged form.

Having fine-grained packages makes a lot of things possible that are difficult otherwise, but we do need to fix the UI.


> the 'leaf' concept in pkg helps with this a bit, but we've always considered FreeBSD bas as a sort of monalithic entity that moves forward together.
> 
> you are running 10.1p8 pr 10.2p1  that tells you all you need to know.
> If you now need to take into account 400 different dimensions you have a much harder way to describe what you have..
> 
> I mentioned this before  but I think hte answer is to make a change on the way that "meta packages" are displayed by default in pkg.

Part of the problem is that we don’t actually have metapackages.  A metapackage is a package that *contains* other packages.  What we actually have is empty packages that *depend on* other packages.  The package tool has no way of distinguishing a package that you install for the sole purpose of installing its dependencies from one that you install because you want it (though having no files inside it might serve as an heuristic that would work).

> If I install the meta package, I really don't want to see all the sub packages tat are unchanged unless I add '-v'.  On the other hand if I upgrade a sub package I want to see that in the context of the metapackage. Similarly if I uninstall of the subpackages.

Doing this properly also requires the notion of optional default and non-default subpackages.  I should be prevented from uninstalling (at least, without a lot of -f) non-optional subpackages.  For example, on a small system where I’m not using zfs, I might uninstall the libzfs subpackage from freebsd-libs, but if I try to uninstall the libc package then the system should shout at me.

> 
> so something like this would remove most of my objections:
> 
> # pkg info
> ===== system packages====
> FreeBSD-networking-11.0.2_1                FreeBSD networking subsystem and commands
> - ipfw-11.0.2-1                           ipfw tools (uninstalled)
> - fbsd-tcpdump-11.0.2-1                   Built in tcpdump tools (uninstalled)
> * openssl-11.0.2-2                        Openssl support (upgraded CVE-123456
> FreeBSD-base-base-11.0.2-1                 The absolute minimum booting base system
> [...]
> ==== external packages ======
> apache22-2.2.31                Version 2.2.x of Apache web server with prefork MPM.
> apr-1.5.2.1.5.4                Apache Portability Library
> autoconf-2.69                  Automatically configure source code on many Un*x platforms
> autoconf-wrapper-20131203      Wrapper script for GNU autoconf
> [...]
> 
> 
> Maybe I uninstalled ipfw because I use pf and I install the ports tcpdump so I can remove the built in one.
> I have installed a new openssl due to a bugfix..
> 
> This gives me a real instant feel for what I'm running..
> if I add -v  then I see all 400 packages, but I really don't want to see them 99.99% of the time
> 
> I believe the "leaf" method gives close to this but if we could get the above I'd have absolutely no objections.

Thank you for this suggestion.  I think that this is the sort of UI that makes a lot of sense (though having subpackage support would also be useful for ports).  It’s also the kind of thing that I think we could persuade the Foundation to fund if there is not enough volunteer time to implement it.

David