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

[Russell L. Carter]

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?
> -Nathan

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

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

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

rcarter at aristotle> dpkg --list | wc --lines
1571

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

rcarter at feyerabend> pkg info | wc -l
      833

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,
Russell















> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"