From nobody Fri Jul 10 18:01:33 2026 X-Original-To: freebsd-pkgbase@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4gxfm76g96z6lTt8 for ; Fri, 10 Jul 2026 18:01:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4gxfm73Z0kz3h9p for ; Fri, 10 Jul 2026 18:01:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1783706496; bh=EgNSxLqbwfkQD+vF/Rqt7jUiqJM1qtbiJFsfj2TH6kE=; h=Date:Subject:To:References:From:Cc:In-Reply-To:From:Subject:Reply-To; b=HsnfeKCv+YY+XQi/wjhnsbiKpH+PVXatyuFRBmAM7h2y84uxU9BWQ1xAKVyCYw6RILsS89mtwNbtEHl9sibFYsV7zVqTXJMCdbITKPsv8slmFHoXzL76h8QKFN8XrUIuUG2lFSKPu7a5tVFw4K34uQV++FfJ6ZCtr1oHk9ZtArrq4abIrT70CENoGJaODnb2p12PjFD6ykn/9ZG7vuWHsGM7mlAdR7QrUerpIHKZFTPCD/ESEU2HVQHpbW6QiBLNkjRFQ2usko3aPI5IcbQsUskdauZf4nHHvCdutyDH0kitZ74LWiKlJ2iPZyFhAsJN4JfM/CZRj1ORobZDip8pzw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1783706496; bh=h9PbVt8qABbc0vz8/zAR1JAGdPCqcbX+HSI3/+7U6us=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=X0x2MMAMcxF4C5op1PFwsa0ExBJS0vAiRUH85Dv6jl1qBPUHHt2CXLJAcHoS9rcJjWnYAYWGFnaZ+ChzWfqwoIlHv1L3GlDtA/T55apU7pGOWk+NGWWqSZlUCdNC0sjNwNG3D+npvQin4KwORw2yiPbcxXdHn93ymWjXZz5nk0Q8OEDpaFGUZfGMoONpLRLv6Dt45P6/9cyFaclyvTWzSpQCX/zqMILjNxMJor+CYuidX5Jts0wm9N0bLmjj6bqpT9mGV+8zDL8GeBnqWjv1nqcEkp3ibJv4F/1NLkg7lawfe3iX1WVOQXFJUWYa/Qn54DY9e45qaRFwnUKizqF6XQ== X-YMail-OSG: 5UgiRKUVM1nBt5_xkVyOoaFFpNMGATP7RQo0vnkcuJICdBmaYBe_WKDd8MNE3TP gCIztxhvcomFsjUVeiTUskm3.vsPiB2PeOzn1qmyk7NAR3yge92wQZ1VtZEB50TjnWmQVI1EB_l7 kwxNr2tsB8KVum_q.r7iPdPOUOhaJlW3rW5Fi9KbankeFPQgmTuO9G89YO8DVi0.IVr3l7kcVVPv m237tTjMqVIuE6Oau0Zu0J.sHiEbIbPhEib7kFa4W5GuvmOnpbkRd4p.7BXPgveeeAtRFWbskDVk R0_4TD3c2vB2v8aAIEZ0sdCMRGAUChDPfaWIIHda8w9qFaG74voPYWaGKz0xLnHXtfMrVyXM.dKs anqD_fqotiHFfWbHafpthk1r1kJ5HMlV4vCFBgKwgleoidH4o_1oY7uzOP4YX32zvbQvNQAdCt9x 5Aw7qKOyXo.rsb_GmEm5dsw9gwXbT13Gfm8_H9.YKuWXNKbdhzZLUw4tKUK6f1EPX_rZc73VS47Z rVZnJ6pE3_65RseMZDVS8s3nzKmuHQ9PZ0rsEhosu0hVnjok1ZmqzWoIVAIrfzzdA3H2iZuM6gRy 2b0Bns5J6_UzNYqxl7xLGEcX.plk5uUQM_2bpdOd483zSor0LS04.q7p3de__G_Wr_4_onLcp7Dc TIf8icxbq1lG5AYQDarFA4GuIpiydAYQqun7X907jOOIAxeGdcrujN8HDrGzA2TfrT1.euGfc2C6 HJpnO_2.S4FvC3exgPFy9VcsLimYYg6CdNOX.sBQqYpEuC3kXmetIAHXjSpx22EbIz..nn8QMC1m GCSlCoAE7CWY3AEgHQmN0eu0zcH02uW7MqSjvcm.0flACehg6K6BEVIXLbdn.uK4yjydx2g82L2J Q.ta_Zcq9O5QoU2PdJ2Y4Jf_c74cK8CR2zH4UX59ynVL5yk8pGyakAHNSXZ72x3xd9mz58oh9omJ 7CvWNFjR5jd0FvwmvV57i7xah9a5b_t9_onRjA82Kc4ZHynCnP5vdke4PEo2aOOd6ukW2aCMdSgr h4.Lc_cCBt3h9NvbEEnsD8n8G6h8MuHAFteLGxFrrBjUWLYWNTFLEZWWGD_Qn3AhDI2yZ17ofkTi e9LdBzT_.xS8JIJ0KP6zi3bJWSSYXutvBHr4R5fCrAUkvgi7pgvCydl89uiojDeTAJEVae85xzOy y7T1TKQEDsm_710iQcStgFjghdUpYGQWJ0NZ4Rh6aFPNP3lNR6AS4rE8YKqsCb04GneMgbfd5q1v Rq6QNuiHyu.sJvl__ptuGW8uC9wLmoy2679Bf.gJGJL..KYVxAq.hWdLC.zPPpJkkqm2h39yAPHx cu_BhdUW28X7hgp4H3TGUg7VmKHN4jnYMyUEVungguTT.c8fc6dJivV_9BoHTnLOMS711K35LZSw gcrnFVJwQGhZIjXkWr_uxnqI9Uvif0GSC9P51g2YUsLj6xNqCWZgIiXLTwzKW0NDvWNSoss8LpsK 4Z5Se_MKrgL_r76XwaiC42LP.9L6PhVgjbotF44C8VYQAyx94Z_EPNrhetHbtZgY6697xj4Ys89l 8OtsBHaJJ9C_RMMxSAqqUVkwWxD3cgISmMj2mQYsTQLhzgXVIHYvVY3m9NSUSSCfXBAgf3HgR8tJ Gn46J3aKUyGG6WEeSwKOluL2fpGJzvQZ47snKNFAPCs_B6y9BYg6S1k_jaY7vqRa6RIfX1jhNJIN HJvGPWs3QmsjEWD5PkStpvMBBqc7QOzaU0kvcJzlj.wTXK8rs2pFCK4by0a5kpz65lvy9zmWdwPH h7QzITEXyZ18fY0.0vPOeS6.7yZGZXGrZ73RJiC0CEu3izJ7wi7FqYXF6u_EDuQffj6btEdrmh2t vGHco_bfaQbRURtxpCCpnCa3gFP8qh_jfrp25tg.AB3hDmKhhbYEj2hYB2.IYhisTsvlrAlWwjmb OuqgZJYwvg74boHAtWTDOvdYeNWbOVkTUUYcE7F8T629RV0qjzo9mG.I4QzwW2qS7QKleq6pBV5s YMLQAHplqvBsM2fjN4G4Fc6QRVJwVOni4.MGfLSQcHCGsA5bmLW_9i81Fn0w.NtsD7Q9BNNiYk7f _KlzaLUKiXcYC20LEDNB_NR6gU0VEZRY2VmjxZy6uFXpJ1qXYQ0jWcHp_BOg5p8b42h5NCL1KJ2G lkhOUC1dsHF2Akbtg7C6UBB31ut8kpEQwgJJFvjrzmCWdiCMyponhJO0gQaQ.rg10QSYaVo.6kAl q_HCSVP86vEkr4WnzKkfbRya5MHvMebuqJlqK8zxMGAZ1OWRqW_XdSIrQkSPYSPUOezu5S0_E6MQ cuP4YgxCbboSeQFtCF7Ul_FNC8MNxXla9LcB4h8DyTP5T4YmsdTvoDSgTLw-- X-Sonic-MF: X-Sonic-ID: fb8cfe45-0b06-49e9-b522-2b1d6db07775 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 10 Jul 2026 18:01:36 +0000 Received: by hermes--production-gq1-6dc558886b-cw7hf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 377b77c9b9cc4d37167cebbd7027efd7; Fri, 10 Jul 2026 18:01:34 +0000 (UTC) Message-ID: Date: Fri, 10 Jul 2026 11:01:33 -0700 List-Id: Packaging the FreeBSD base system List-Archive: https://lists.freebsd.org/archives/freebsd-pkgbase List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkgbase@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: pkg upgrade yields conflicts in message To: Mike , freebsd-pkgbase@FreeBSD.org References: <62849618-c9b7-4310-8555-cf7a91e4af9d@mgm51.com> <4e9a04c9-512c-44c0-8e0c-3da2704da608@yahoo.com> <2ef5ceae-791f-486a-bc5a-504dc4a97f61@mgm51.com> Content-Language: en-US From: Mark Millard Cc: Lorenzo Salvadore In-Reply-To: <2ef5ceae-791f-486a-bc5a-504dc4a97f61@mgm51.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.26136 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Rspamd-Queue-Id: 4gxfm73Z0kz3h9p X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- 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