[Bug 263879] pkgbase removes critical etc files upon upgrade

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 21 Sep 2022 17:34:08 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263879

Mark Johnston <markj@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bapt@FreeBSD.org,
                   |                            |manu@freebsd.org

--- Comment #3 from Mark Johnston <markj@FreeBSD.org> ---
I hit this again today with a plain "pkg upgrade" from my pkgbase repo.  After
fetching packages, I see:

Checking integrity... done (3 conflicting)                                      
  - FreeBSD-utilities-14.snap20220918044710 [FreeBSD-base] conflicts with
FreeBSD-runtime-14.snap20220902044459 [installed] on /etc/termcap.small
  - cmake-man-3.23.3 [FreeBSD] conflicts with cmake-3.23.3 [installed] on
/usr/local/man/man1/ccmake.1.gz
  - cmake-core-3.23.3 [FreeBSD] conflicts with cmake-3.23.3 [installed] on
/usr/local/bin/ccmake

Then, during the upgrade itself:

[1/421] Upgrading libxml2 from 2.10.1 to 2.10.2...                              
[1/421] Extracting libxml2-2.10.2: 100%                                         
[2/421] Upgrading ca_root_nss from 3.81 to 3.83...                              
[2/421] Extracting ca_root_nss-3.83: 100%                                       
[3/421] Deinstalling FreeBSD-runtime-14.snap20220902044459...                   
[3/421] Deleting files for FreeBSD-runtime-14.snap20220902044459: 100%          
[3/421] Installing FreeBSD-runtime-14.snap20220918044710...                     
[3/421] Extracting FreeBSD-runtime-14.snap20220918044710:   1%                  
pkg: getgrnam_r(operator): No such file or directory
     ^--- /etc/group is toast
...

So for some reason pkg's solver decided to split the upgrade job for
FreeBSD-runtime, but
- In general it must not do this, it's not ok to lose /etc files of course.
- The deinstall and install of -runtime were back-to-back, so splitting the job
does not seem to accomplish anything.

The above happened on a test box and I can reproduce it.  Any hints on what
debug info to look at would be appreciated.  I will try to figure out why the
solver is splitting the job, since that behaviour seems wrong.

-- 
You are receiving this mail because:
You are the assignee for the bug.