Bug 254367 - etcupdate status should exit with rc != 0 whenever there is one or more conflicts
Summary: etcupdate status should exit with rc != 0 whenever there is one or more confl...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-03-17 20:14 UTC by Trond Endrestøl
Modified: 2021-04-22 19:22 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 freebsd_triage 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.