Re: pkg upgrade yields conflicts in message

On 7/10/2026 2:01 PM, Mark Millard wrote:
> 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.  :)
> 

 > 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.


Yeah, that aside.

I look to FreeBSD as a stable operating system and trust it (and ZFS) to 
take care of my multiple-terabytes of data on my FreeBSD data server.

So let me ask a question to the list ...

Would you trust multiple terabytes of data to an OS that is presenting 
you with conflict warning messages?

imo, the pkg/port folk of FreeBSD need to get their act together.

Enough of the attempted rationalizations of the conflicts.

Just fix the problem.

Period.  Full stop.