Bug 254367

Summary:	etcupdate status should exit with rc != 0 whenever there is one or more conflicts
Product:	Base System	Reporter:	Trond Endrestøl <Trond.Endrestol>
Component:	bin	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	New ---
Severity:	Affects Only Me	CC:	emaste, jhb
Priority:	---
Version:	CURRENT
Hardware:	Any
OS:	Any

Description Trond Endrestøl 2021-03-17 20:14:16 UTC

On a test VM running 13.0-CURRENT with the source tree fully updated, coming from Subversion, I ran:

# etcupdate extract
# etcupdate -p
# etcupdate

So far, so good. The running system was also updated to the last Subversion commit for base/head.

I then prepared 14.0-CURRENT with the source tree this time coming from Git, branch main, and I ran:

# etcupdate extract
# etcupdate -p
<Output omitted>
# etcupdate
<Lots and lots of output omitted>
# etcupdate status && echo All is OK
  C /etc/newsyslog.conf.d/lpr.conf
  C /etc/newsyslog.conf.d/pf.conf
  C /etc/newsyslog.conf.d/ppp.conf
  C /etc/newsyslog.conf.d/ftp.conf
All is OK
# etcupdate resolve
<Choose e for edit, edit to your heart's content, save and exit, choose r to mark as resolved, and rinse and repeat for the remaining files.>
# etcupdate status && echo All is OK
All is OK

In my opinion, "etcupdate status" should not exit with rc = 0 when there is one or more unresolved conflicts present. This follows from the manpage, "The etcupdate utililty exits 0 on success, and >0 if an error occurs.", and also from a desire to use etcupdate(8) in a shell script like this:

etcupdate -p
etcupdate resolve -p

etcupdate
etcupdate resolve
while ! etcupdate status; do
  etcupdate resolve
done

A workaround is to use the condition: ! etcupdate status | grep -q '^  C'

I guess it's up to interpretation on whether conflicts of this nature should be regarded as errors. I appreciate all feedback on the matter.

Also, could we have "etcupdate status -p" too?

Comment 1 Trond Endrestøl 2021-03-18 18:08:21 UTC

Sorry, it was late in Norway.
A workaround is to use the condition: etcupdate status | grep -q '^  C'

Comment 2 John Baldwin freebsd_committer

2021-04-22 19:22:27 UTC

Hmm, this sounds like a good idea.

In regards to 'etcupdate status -p', what would that do?  'etcupdate status' already reports any status after 'etcupdate -p' as there is a single, shared conflicts/ tree, and a shared warnings file, so a bare 'etcupdate status' after 'etcupdate -p' should report the right status to permit, for example:

etcupdate -p
while ! etcupdate status; do
    etcupdate resolve -p
done
etcupdate
while ! etcupdate status; do
    etcupdate resolve
done

One question is what should etcupdate status report if there are no conflicts but there are warnings (warnings can be for things like needed post-install actions that can't be performed in a chroot)?  These potentially still require user intervention.