On 20/04/2016 11:41 AM, Nathan Whitehorn wrote:
On 04/19/16 20:15, Warner Losh wrote:
On Apr 19, 2016, at 4:12 PM, Matthew Grooms <mgro...@shrew.net>
Sadly the tenor and tone of the discussion isn’t one where progress
is made. The tone has been a bit toxic and demanding, which grinds
people into dust, rather than motivating them to fix things. You
might call it a discussion, but it reads to me more as a bunch of
angry villagers storming the castle. No good can come from that.
Tone down the outrage by a factor of 100 and try to have the
On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote:
Maybe I missed an email in this thread, but I don't recall anyone
completely rejecting the idea of packaging the base system. What I
see is a discussion related to doing it in the best way possible.
As far as I know, nobody is taking the source code or the Makefiles
away, so if somebody doesn't like the system being distributed with
pkg, they can very well roll their own.
It's nice to see the level of enthusiasm the FreeBSD project can
muster, I just wish it wasn't always enthusiasm for stopping
Yes, and that tone raises everyone's defensive hackles, which is
never good. I'm going to make a patch for a reduced package count
and hopefully we can restart this discussion then.
It would also be nice to get a statement of what the intended scope
of these patches is from some of the people involved in the project.
It's a major change to the system and it would be nice to have some
kind of architectural document about what is happening. I'm not
sure, for instance, what the release for 11 looks like with these
changes, what changes need to be made to the installer (something of
particular interest to me), how we build install media now that base
is no longer self-contained (due to lack of pkg), what specific
problems were intended to be solved, how package dependencies work,
etc. Something like a few-page white paper would be *really* helpful
for those of us who weren't at the BSDcan where this was discussed.
Even a wiki page would help a lot.
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.
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
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.
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.
so something like this would remove most of my objections:
# pkg info
===== system packages====
FreeBSD-networking-11.0.2_1 FreeBSD networking subsystem and
- 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
==== external packages ======
apache22-2.2.31 Version 2.2.x of Apache web server with prefork
apr-18.104.22.168.5.4 Apache Portability Library
autoconf-2.69 Automatically configure source code on many Un*x
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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"