pkg upgrade vs building from source

From: paul beard <paulbeard_at_gmail.com>
Date: Sat, 08 Oct 2022 15:35:39 UTC
My skepticism over pkg doing what I expect grows after recent events. I
decided after I rebuilt this freebsd instance that I would say goodbye to
installing from source and allow pkg to manage it all. Surely by now, it's
mature enough to handle it.

Reader, it is not.

I allowed it to upgrade postfix the other day and discovered that it no
longer worked;
Oct  8 03:15:16 <mail.warn> www postfix/smtp[65148]: warning: unsupported
SASL client implementation: cyrus
Oct  8 03:15:16 <mail.crit> www postfix/smtp[65148]: fatal: SASL library
initialization
Oct  8 03:15:17 <mail.warn> www postfix/master[1157]: warning: process
/usr/local/libexec/postfix/smtp pid 65148 exit status 1
Oct  8 03:15:17 <mail.warn> www postfix/master[1157]: warning:
/usr/local/libexec/postfix/smtp: bad command startup -- throttling

I went to the port directory and did a deinstall/reinstall and all is well.
Postfix flush cleared out the test emails I had queued up and no errors in
maillog. No changes to teh configuration files, it just worked properly
after a proper install.

I can obviously issue pkg lock against postfix to ensure it's left alone
but I have to wonder how many other ports are similarly not ready for prime
time after pkg gets involved? One of the reasons I tried freebsd, all the
way back to release 4.11, is that rpm in the linux world was a massive pile
of inconsistency. The ports system was so coherent and well managed: I
preferred the cathedral to the bazaar, as a book of the period described
that time.

I suppose not trusting pkg with ports you rely on seems reasonable but with
dependencies and whatnot, how to decide? Should pkg include some more
robust testing to ensure services are actually running after upgrade? I
don't know if it could but I suppose the maintainer could devise some
tests, looking at logfiles or whatnot.

All in all, not how I expected to spend a half hour on Saturday morning.
How do other people manage this?



--
Paul Beard / www.paulbeard.org/