Re: pkg upgrade yields conflicts in message

On 7/10/26 09:36, Mike wrote:
> 
> 
> On 6/27/2026 12:37 AM, Mark Millard wrote:
>> On 6/26/26 15:54, Mike wrote:
>>> OK, I have a 15.1 test system, loaded with FreeBSD 15.1 AMD from a
>>> mem img.
>>>
>>>
>>> I went through the install, which went well.
>>>
>>> Then I loaded the ports pkgs I usually use, which also went well.
>>>
>>>
>>> Now, when I run
>>>      pkg upgrade
>>> as I had usually done to see if there were any updates to the ports pkgs
>>> I had installed, I see the following ...
>>>
>>> ====================
>>>
>>> Updating FreeBSD-ports repository catalogue...
>>> FreeBSD-ports repository is up to date.
>>> Updating FreeBSD-ports-kmods repository catalogue...
>>> FreeBSD-ports-kmods repository is up to date.
>>> Updating FreeBSD repository catalogue...
>>> FreeBSD repository is up to date.
>>> All repositories are up to date.
>>> Checking for upgrades (15 candidates): .......... done
>>> Processing candidates (15 candidates): .... done
>>> Checking integrity... done (9 conflicting)
>>>    - libcdb-g2020082801 [FreeBSD-ports] conflicts with tinycdb-0.81
>>> [installed] on /usr/local/lib/libcdb.a
>>
>> One of the Makefiles is explicit about it:
>>
>> # grep -r CONFLICT /usr/ports/*/*cdb/Makefile
>> /usr/ports/databases/tinycdb/Makefile:CONFLICTS_INSTALL=        libcdb #
>> lib/libcdb.a

My notes here are about the lang/gcc* part of things.

>>
>>>    - gcc14-14.2.0_4 [FreeBSD-ports] conflicts with gcc14-
>>> devel-14.3.1.s20260327,1 [installed] on /usr/local/bin/c++14
>>>    - gcc14-14.2.0_4 [FreeBSD-ports] conflicts with gcc14-
>>> devel-14.3.1.s20260327,1 [FreeBSD-ports] on /usr/local/bin/c++14
>>>    - gcc13-13.3.0_3 [FreeBSD-ports] conflicts with gcc13-
>>> devel-13.4.1.s20260326 [installed] on /usr/local/bin/c++13
>>>    - gcc13-13.3.0_3 [FreeBSD-ports] conflicts with gcc13-
>>> devel-13.4.1.s20260326 [FreeBSD-ports] on /usr/local/bin/c++13
>>>    - gcc12-devel-12.4.1.s20250702 [FreeBSD-ports] conflicts with
>>> gcc12-12.4.0_3 [installed] on /usr/local/bin/c++12
>>>    - gcc12-devel-12.4.1.s20250702 [FreeBSD-ports] conflicts with
>>> gcc13-13.3.0_3 [FreeBSD-ports] on /usr/local/include/libgccjit++.h
>>>    - gcc12-devel-12.4.1.s20250702 [FreeBSD-ports] conflicts with gcc13-
>>> devel-13.4.1.s20260326 [installed] on /usr/local/include/libgccjit++.h
>>>    - gcc12-devel-12.4.1.s20250702 [FreeBSD-ports] conflicts with gcc13-
>>> devel-13.4.1.s20260326 [FreeBSD-ports] on /usr/local/include/
>>> libgccjit++.h
>>
>> Some lang/gcc* vs. lang/gcc*-devel conflicts are not new and are
>> documented in the Makefiles:
>>
>> # grep -r CONFLICT /usr/ports/lang/gcc*/Makefile
>> /usr/ports/lang/gcc12-devel/Makefile:CONFLICTS= gcc12
>> /usr/ports/lang/gcc12/Makefile:CONFLICTS=       gcc12-devel
>> /usr/ports/lang/gcc13-devel/Makefile:CONFLICTS= gcc13
>> /usr/ports/lang/gcc13/Makefile:CONFLICTS=       gcc13-devel
>> /usr/ports/lang/gcc14/Makefile:CONFLICTS=       gcc14-devel
>> /usr/ports/lang/gcc15/Makefile:CONFLICTS=       gcc15-devel
>> /usr/ports/lang/gcc16/Makefile:CONFLICTS=       gcc16-devel

lang/gcc1[23]* all conflict with each other for:
/usr/local/include/libgccjit++.h The file is in the wrong place for
allowing independent installations.

Also, the lang/gcc1[456]-devel ones not listing the matching non-devel
one as conflicting may set up for the -devel ones to be preferred (since
it is not declared to have conflicts). (Seems to have listed the wrong
direction if only one direction of conflict is to be listed:
lang/gcc*-devel likely should never be considered preferred.)

This much looks like port issues to me, not directly pkg issues. pkg has
been given garbage-in (incomplete) information when it has to deal with
simultaneous installs.

(The above is separate from the general question of why all the variants
were considered in the first place. That might be more of a pkg issue.
See later note.)

>>
>> (Looks like lang/gcc[456]-devel do not document that other direction for
>> the conflicts. and 12-devel and 13 did document their conflict status.)
>>
>> However, if I understand right, modern pkg has gotten better at
>> detecting and reporting conflicts, with an example file as well more of
>> the time, even when the Makefiles are not explicit.
>>
>>> Checking integrity... done (0 conflicting)
>>> Your packages are up to date.
>>>
>>> ==========================================
>>>
>>>
>>> A comment ...
>>>
>>> I dislike seeing the word "conflicting" in the routine commands I run.
>>>
>>> What did I do incorrectly?
>>
>> Looks like no 2 installs conflict with each other. I'm not sure that you
>> did anything incorrectly.Mostly you have -devel installs for gcc* but
>> one of them is not: gcc12-12.4.0_3 [installed] . Is that as you intended?
>>
> 
>> Is that as you intended?
> 
> I didn't change any of the options to use -devel installs.  I suspect it
> was done by one of the pkgs I installed.  That's why I asked.

Well, as I understand it, pkg deals with such conflicts by picking a
non-conflicting subset when it can. (It may have a biased to preserve
what is already installed, I'm not sure.)

Nothing present forced it to pick the non-devel lang/gcc* alternatives,
although non-devel lang/gcc* are normally preferable (when available)
unless one is deliberately testing lang/gcc*-devel usage:
lang/gcc*-devel are upstream in-development versions leading to the next
releases and they update more often than the non-devel variants and have
a more uncertain status from update to update until released.

In other words, absent detailed information about the context, I'd guess
that the lang/gcc*-devel usage should be replaced by non-devel usage.

> 
> So far, everything on the test server has been running as expected, in
> spite of those conflicts.  But it is a minimal-usage server.  So I'll
> just go along with them for now.

This could be a good reason to force each -devel variant to be replaced
by the matching non-devel variant. (But I do not know the context.)

> 
> However, I may have a higher level of concern when it comes to moving my
> two production servers over to the pkg install system when (if) such
> conflicts continue to occur with generic pkg installs.

I do not really have enough established context to attempt replicating
so many lang/gcc* being under consideration in an way analogous to
whatever  happened for you. I've only enough context to identify the
issues with how lang/gcc* have been defined.

> 
> Thanks for your explanation.
> 
> And I apologize for taking so long to get back to you.  Life happened.  :)

-- 
===
Mark Millard
marklmi at yahoo.com