On 04/19/16 11:22, Nathan Whitehorn wrote:

On 04/19/16 10:55, Roger Marquis wrote:
Please, consider ops and admins, who must support old installations,
often made by other, not-reachable, people, and stuff like this,

Ops and admins such as myself are exactly the ones who will benefit most
from base packages.  Being able run to: 1) 'pkg audit' and see that base
ssl has a vulnerability, 2) 'pkg install -f' to update 3) only those
specific parts of base that need to be updated is far simpler (KIS) and
faster than what we go through now.  More than a few formerly bsd shops
have migrated to linux simply to avoid regular iterations of cd
/usr/src; svn up; make cleanworld; make buildworld installworld ...

The use cases for granular base packages are more numerous than even
these obvious ones.  The downside OTOH, seems to consist of not much
more than the size of the package list.  If I missed other issues please
do clarify.  Will base packages be improved, sure, but they're already
more useful and bugfree than pkgng when it was mandated.

In any case, if I'm not mistaken base packages are entirely optional.

Roger Marquis

Thanks, Roger. That seems perfectly reasonable. I'm not sure that goal
is really met by having 800 packages, though, or at least I see no
particular gain relative to a handful (where things like OpenSSL or
sendmail would be discrete things). (Almost) every single individual
library in the base system is right now its own single-file package,
which is what I am objecting to. The upside of that seems pretty dubious
and the downside is that it is much easier to accidentally put the
system into an inconsistent state. Is there a reason you want to have
such very fine discretization?

What is missing from this debate is some perspective from the POV of
actually existing packaging systems.  I've been maintaining
debian-stable + debian-testing systems for over 15 years.  The number
of packaging glitches I've had I can count on one hand.  (I've been
running FreeBSD systems since the *very* beginning.)

It is much easier to maintain my debian systems than my FreeBSD
systems.  Actually, pkg + poudriere is like a dream.  Better than
apt-get, actually.  Except right now it doesn't maintain the base

So, how many packages are actually installed on one of my debian

debian-testing box with fvwm (ie no gnome/kde) userland:

rcarter@aristotle> dpkg --list | wc --lines

FreeBSD-10/stable with the same userland packaged from ports:

rcarter@feyerabend> pkg info | wc -l

The debian system, for basically identical functionality, installs 738
more packages.  Obviously the FreeBSD box has no packages for the base
system, so that is probably a significant part of the difference in
installed packages.  And the debian box is dramatically easier to
maintain.  I typically will drag a debian box across several debian
release cycles, i.e., 6+ years, w/o ever doing anything more
complicated than doing apt-get update; apt-get dist-upgrade every week
or so.

Now I much prefer poudriere + pkg over apt-get, because I can tune my
package dependencies.  What I do is make the implicit meta-packages
effectively even more fine grained, by excluding stuff I don't need.
My conclusion is that it's not obvious that a large number of packages
makes a system harder to maintain.  It seems to me, the opposite.  Now
I watch a few debian lists so I know glitches happen, but not to me
very often.

I don't have much experience locking down a system to just major
releases with only security updates, but I don't think debian-stable
has very many issues doing exactly that.

In my opinion, what the package team is doing is extremely cool,
technically.  I run poudriere builds every night, keeping up to date
with ports-svn.  It's just so much better than debian's kitchen sink
one-size-fits-all approach to package dependencies.  In a container
world, it seems to me this is basically a killer app.

Best to all,

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to