Re: pkg upgrade yields conflicts in message

On 7/18/26 01:45, Mark Millard wrote:
> On 7/17/26 22:29, Mike wrote:
>>
>> OK, I had been critical of the "conflicts" presented in pkgs.
>>
>> Today, I performed an update,
>> Many, many! gcc updates downloaded and installed.
>>
>> And, after the update, lo and behold ...
>>
>> No conflicts noted!
>>
>> .....
>>
>> # pkg-do-upgrades.sh
>> 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 (0 candidates): 100%
>> Processing candidates (0 candidates): 100%
>> Checking integrity... done (0 conflicting)
>> Your packages are up to date.
>>
>> .....
>>
>>
>> Of course, there still remains the questions for me...
>>
>> Why do I need to download and install all of ...
>>
>> gcc12-12.4.0_5                 GNU Compiler Collection 12
>> gcc13-devel-13.4.1.s20260624   GNU Compiler Collection 13
>> gcc14-devel-14.3.1.s20260618,1 GNU Compiler Collection 14
>> gcc15-15.2.0_3                 GNU Compiler Collection 15
>> gcc16-devel-16.1.1.s20260627   GNU Compiler Collection 16
>> gcc17-devel-17.0.0.s20260621   GNU Compiler Collection 17
>>
>>
>> on the server?
>>
>> Six different versions of gcc??
>>
>> I mean really, can't FreeBSD get its collective act together and move
>> towards one or two, even three versions of gcc?
> 
> No set of FreeBSD Volunteers have agreed to do such a thing for you. Are
> you volunteering to work on the problem? (It does not sound like it.)
> 
> There are 6 lang/gcc*-devel that are test builds of upcoming updates (or
> first release) to the matching non-devel variant. So the total is more
> like 11 port-packages, as stands.
> 
> It is also the case that 1 or 2 of the non-devel ones are gcc* releases
> that provide a context for working on updating port-packages to use them.
> 
> As for the non-devel ones otherwise (gcc12 . . . gcc16):
> 
> There are 35000+ FreeBSD port packages, some fraction of which are
> directly based on using a lang/gcc* and some which may be dependent on
> those but do not use a lang/gcc* directly. The port packages are not
> based on native FreeBSD source code but on upstream projects, some of
> which make little effort to support FreeBSD and some of which support a
> range of OS's that do not agree on what vintage(s) of gcc* to have
> around. FreeBSD does not have the resources to update all those upstream
> projects. Those upstream projects are not all time/gcc-version synchronized.
> 
> It takes a notable time for most all of the lang/gcc* port-packages to
> be ready for the next default lang/gcc* . Each does not generally start
> to update until sometime after its next lang/gcc* is available in the
> ports tree.
> 
> The devel/electron*'s have the same sort of issue, but a comparatively
> tiny number of port-packages dependent on them --but some of those may
> be heavily used. There are 7 different devel/electron* , 6 of which are
> commonly blacklisted because it is so resource intensive to build the
> whole set of them.
> 
> There is a list of lang/llvm* as well. There are other examples of such
> for toolchains.
> 
> Why your context ends up with lang/gcc*-devel usage, I have no idea.
> 
> A command like:
> 
> # pkg query -g '%o : %#r' lang/gcc\*-devel
> 
> should report how many port packages are directly dependent on
> lang/gcc\*-devel port packages (in your environment).
> 
> # pkg query -g '%o : %rn-%rv' lang/gcc\*-devel
> 
> should provide port-package names.
> 
> Another way is to do a pkg delete of such a port-package to see what it
> reports would be deleted.
> 
>>
>> But six?
> 
> 11 as stands.
> 
>>
>> Wow.
> 
> Having probably hundreds of port-packages dependent on one a lang/gcc*
> leads to non-trivial efforts being involved in progressing over time.
> 
> 

FYI: Based on an amd64 context looking at the upstream 15.0 port-package
repository (via a locally created repo name that points upstream) and
skipping  the large output for gcc14 (non-devel):

# pkg -oABI=FreeBSD:15:amd64 -oOSVERSION=1500000 \
      rquery -rFreeBSD-ports-release-latest \
             -x -e '%#r > 0' '%rn-%rv : %n %v' 'gcc[0-9][0-9].*' \
| grep -v ' : gcc14 '
pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap
-f" recommended
gnat12-12.4.0_1 : gcc12 12.4.0_5
cgicc-3.2.20_1 : gcc12 12.4.0_5
emacs-30.2_4,3 : gcc13 13.3.0_5
emacs-devel-32.0.50.20260704,3 : gcc13 13.3.0_5
emacs-devel-nox-32.0.50.20260704,3 : gcc13 13.3.0_5
emacs-canna-30.2_4,3 : gcc13 13.3.0_5
emacs-wayland-30.2_4,3 : gcc13 13.3.0_5
x49gp-20100425_9 : gcc13 13.3.0_5

So nothing is indicates as being dependent on any gcc*-devel --nor on
gcc15 nor on gcc16 .

gnat12 , cgicc , various emacs-* , and x49gp are known to depend on
either gcc12 or gcc13. The maintainers (if any) of each of those would
who to ask about why they do not use the default gcc14.

(Analogous could be done for 14.4 instead of 15.0 .)

There are lots of ports indicated as dependent on gcc14:

# pkg -oABI=FreeBSD:15:amd64 -oOSVERSION=1500000 \
      rquery -rFreeBSD-ports-release-latest \
             -x -e '%#r > 0' '%rn-%rv : %n %v' gcc14 \
| wc -l
pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap
-f" recommended
     767

None of this indicates why you ended up with a bunch of gcc*-devel port
packages. I do not know if it explains anything for you having gcc12
and/or gcc13 or not.


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