Re: Port conflicts, again
Mark Millard <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.ports |
|---|---|
| Message-ID | <[email protected]> |
On 8/27/26 19:02, Mike wrote: > > OK, it is occurring again ... > > # uname -a > FreeBSD t01.24cl.home 15.1-RELEASE-p3 FreeBSD 15.1-RELEASE-p3 > releng/15.1-n283611-88e7371d9dc2 GENERIC amd64 > > > Using the pkgs version ... > > I see, when I when I run ... > > ---- > /usr/sbin/pkg upgrade --repository FreeBSD-base \ > --fetch-only --yes (One of my context's outputs follows, not yours.) # which pkg /usr/sbin/pkg # which pkg-static /usr/local/sbin/pkg-static # ls -lod /usr/sbin/pkg* /usr/local/sbin/pkg* | grep -v _ -rwxr-xr-x 1 root wheel - 3882616 Aug 12 18:05 /usr/local/sbin/pkg -rwxr-xr-x 1 root wheel - 40205696 Aug 12 18:05 /usr/local/sbin/pkg-static -r-xr-xr-x 1 root wheel - 589240 Aug 24 04:49 /usr/sbin/pkg So what do the following report? : /usr/sbin/pkg -v /usr/local/sbin/pkg -v /usr/local/sbin/pkg-static -v You do not show output from any of: /usr/sbin/pkg repos /usr/local/sbin/pkg-static repos /usr/local/sbin/pkg repos in order to indicate the what names are bound to what repositories (upstream or local). Do all 3 commands support "repos" (vintage evidence)? And, for each repository what version/vintage of pkg's are in the repository? > > --- > > I saw ... > > --- > > Updating FreeBSD-ports repository catalogue... > FreeBSD-ports repository is up to date. Whatever version of pkg attempted this update ignored the intended status of: --repository FreeBSD-base Only FreeBSD-base should have been updated and used to upgrade. As stands this suggests use of a pkg old enough to not have the modernized support of --repository . (This repeats below for other example messages.) > Updating FreeBSD-ports-kmods repository catalogue... > FreeBSD-ports-kmods repository is up to date. Whatever version of pkg attempted this update ignored the intended status of: --repository FreeBSD-base Only FreeBSD-base should have been updated and used to upgrade. As stands this suggests use of a pkg old enough to not have the modernized support of --repository . > Updating FreeBSD repository catalogue... > FreeBSD repository is up to date. Whatever version of pkg attempted this update ignored the intended status of: --repository FreeBSD-base Only FreeBSD-base should have been updated and used to upgrade. As stands this suggests use of a pkg old enough to not have the modernized support of --repository . You have both FreeBSD-ports (modern naming) and FreeBSD (old naming) in use. They may well not be the same repository by content. So far as I know, this gets into the variant of pkg that was executed at the time having been out of date, prior to the correction that was made to match the documented behavior. (I've no clue if the versions now in place are the same as then.) > All repositories are up to date. > Checking for upgrades (17 candidates): .......... done > Processing candidates (17 candidates): ...... done > Checking integrity... done (13 conflicting) > - libcdb-g2020082801 [FreeBSD-ports] conflicts with tinycdb-0.81 > [installed] on /usr/local/lib/libcdb.a Do FreeBSD-ports and FreeBSD agree for what versions of packages are referenced? Did you intend on having both FreeBSD and FreeBSD-ports in use? If both are intended, what have you done to control which repository is used when there are differences? I had already documented the Makefile CONFLICT declarations were incomplete (such was not pkg's problem). In the above case: QUOTE 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 END QUOTE > - gcc14-14.2.0_6 [FreeBSD-ports] conflicts with gcc14- > devel-14.3.1.s20260618,1 [installed] on /usr/local/bin/c++14 > - gcc14-14.2.0_7 [FreeBSD] conflicts with gcc14- > devel-14.3.1.s20260618,1 [installed] on /usr/local/bin/c++14 > - gcc16-16.1.0_2 [FreeBSD-ports] conflicts with gcc16- > devel-16.1.1.s20260627 [installed] on /usr/local/bin/c++16 > - gcc16-16.1.0_3 [FreeBSD] conflicts with gcc16-devel-16.1.1.s20260627 > [installed] on /usr/local/bin/c++16 > - gcc15-devel-15.3.1.s20260626 [FreeBSD-ports] conflicts with > gcc15-15.2.0_3 [installed] on /usr/local/bin/c++15 > - gcc15-devel-15.3.1.s20260814 [FreeBSD] conflicts with gcc15-15.2.0_3 > [installed] on /usr/local/bin/c++15 > - gcc13-13.3.0_5 [FreeBSD-ports] conflicts with gcc13- > devel-13.4.1.s20260624 [installed] on /usr/local/bin/c++13 > - gcc13-13.3.0_6 [FreeBSD] conflicts with gcc13-devel-13.4.1.s20260624 > [installed] on /usr/local/bin/c++13 > - gcc12-devel-12.4.1.s20250702 [FreeBSD-ports] conflicts with > gcc12-12.4.0_5 [installed] on /usr/local/bin/c++12 > - gcc12-devel-12.4.1.s20250702 [FreeBSD-ports] conflicts with > gcc13-13.3.0_5 [FreeBSD-ports] on /usr/local/include/libgccjit++.h > - gcc12-devel-12.4.1.s20250702 [FreeBSD-ports] conflicts with > gcc13-13.3.0_6 [FreeBSD] on /usr/local/include/libgccjit++.h > - gcc12-devel-12.4.1.s20250702 [FreeBSD-ports] conflicts with gcc13- > devel-13.4.1.s20260624 [installed] on /usr/local/include/libgccjit++.h QUOTE 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.) END QUOTE I'll not repeat my other old notes but stop with that for quotes. Something I did not get into last time as far as I remember --but should have--: What installed packages had the pre-upgrade status's: ) automatic (e.g., subject to autoremove, indirectly installed) vs. ) non-automatic (e.g., not subject to autoremove, directly installed) > Checking integrity... done (0 conflicting) > Your packages are up to date. > > --- > > Now when I run that same command, all those conflicts have seemed to > have disappeared. > > Just happiness and rainbows. > > What is going on with the FreeBSD updates? > > > Why do they seem to be so volatile? What you present looks like an incoherent context to me (after it became incoherent), like last time looked. (I.e., too late to identify the first problem when it first occurred and what was going on that lead to such.) I'll note that since last time, as far as I remember, you still have the only known context with such examples with no one else reporting such issues. pkg bugs may be involved, but it seems that a basic identification needed is identifying the unique issue/operation(s) in your context that are involved that start the problem, in order to have something to investigate the internal details of. It would help if the port Makefiles involved had a complete set of CONFLICTS and/or CONFLICTS_INSTALL declarations in place. (I've not noticed any such updates go by.) I assume that at this point you do not know how to start from scratch and use a fixed/reproducable list of steps to reproduce the problem. Absent others being able to do so, you have the only known test environment and only your activity leads to replication so far. That makes you the investigator for now, unfortunately. > > > > > -- === Mark Millard marklmi at yahoo.com