From nobody Thu Apr 2 18:24:38 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 4fmqyX6d0Lz6YVJ2 for ; Thu, 02 Apr 2026 18:24:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.205]) (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 4fmqyX29TMz3Sdv for ; Thu, 02 Apr 2026 18:24:52 +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=1775154285; bh=BGRxvJ1ORtopRNbmZfl9TrDeapn0pVMNACYdlPD3VDg=; h=Date:Subject:To:References:From:Cc:In-Reply-To:From:Subject:Reply-To; b=ZK6kUmcxf23Mhh3f/31oEjsMQpLHFh0YZ788+03CyblPB0utfGc7PzqBE38iLxl0m88U9saMTdF2tVNRP6ZIbMGtIKSRUmvwc/bIc8oR9B8BlCrtZAdy/M4tt6W9uvu4zQzJSZDyEAI25W7aPNpj8f0P/MkKopC6XgKo58nVP2CyLTtnZTo6vw7FyLVcyzAaqMH+kHwDjPGHpWNxuEnqBbSsX8F0UXui155oxcNVGkEHs9qsB409bx4vhFKRT0se9GSecrsBzd/odU0wYMtDuszCe+xviyCHIscflHGCALVh0LqKJvwtI/dP9LLJ9Jz9AT+8byR6CwQbcHHEJGf2+Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1775154285; bh=ZwwU6ELyuMq7X0Vy++rWi2Rbi4EaMm4vLlGa0WYz0ks=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=qJh3MbQ6RTCfv9LbBRlbLERE6XepYgtCedvWPayzWtwnurSkF8CWvW5dA5mqsN9OH7dQbc5N0V6D6DkZyDlwdi2Rwxgu9ijDOBVY2HW4bqv3a28pozrYHeDT/dqKdfPWYjblowyaB9ISK0Aa1aH3+yllZPKLrO0Hpt49eNt4K0WMm0VgT3A3dorU6ZpD3VfwQ2x2e6yryaEtUjg+ayD4oJc1zTirrd/UyiEVqYZZHX3uY8p8ilCftLFqFdKEDEATNiCdV6CvERnZxpfxCIRms+JszvMKgrGFj+hiKB+RomurLaQr/04JpkQqTMqBP8yJiBYbpshScIahgwUpsCQH5w== X-YMail-OSG: P9pJoSQVM1mIrwPM9t02u5QWaZWUIS.11qz2wSkIaOsjVZUx4TiaVxbnC3rYJxV PkBxAsqvGBpmI4nZKAHVN4y1ym2GvevJHgPNRPpNNT5jg7IvVb10t3guQReLXwrxCV8kGk2965z1 92BrBcNrwOlLqLwufWwuzFLgLMWBCRtWBufLSd5iRi8_ZzXnSdNGqKxHfGHwuJxanA1Se14jbjVI .rjT32KucblN0VIt8iVX80zAGdEOdb7EEWi49kosPEaw3KA0syi_5.bbgHqd52b5cXZLL.FKUfz_ YfVEG0KCIVS9w0dQeE65ImDFJBi2CpCUrylsFK9yedBBSL3bputHaKsYbR..OakBqg8GLSMMt8Ii tfaOTjLb9upHedt79s5MaqRnJN5kJvWBR7DDHy1TwcxOLyg.oxZn9ia700sIm5NEXyrDMCqvixtY vOz238sKvqa90J1WlQ8LPwnJWGVNByfcDjW7fsid_zn4uqRJOqHyX.x1WDpeefnROywytecH.EUV c467.N.622jmqsnW2fLDI5XPxKSrQgt07OlMQswltIX_FraQtvL0GHWF_DNAPG20dgsJQbT0ez4W EA9Qt6_TUzZd47lD5XBMMUbgqKOlQVGSuJ5sbdoEGDZ3PNBuJqeORjv_ZJCiGSqv.OwS9XjVSOrF Pn3mmgbnkFdjbVFtCrwnDMs93C1ZvPsnXwMoLJiZFDH7MZW4V19wjWWXPnpSL5mBkmA7sZcM4ibw wMYn2XA2uOgcyUxd._Ut8KBFp63sRTDCqR5vVM0LcMkskujOfnegxGFyIJ2WjRDwxL8qYKr2jiEi oS1zf5yYsjxZWjd1LwWvmIOjLPCwY7_fga0tGDe7HBRIUcC2qMnmxildTuqO1rks.Jz5JaK06lVM NYaUAyP4rg2jVXIwtiCBy4XveDm8hwkouRFN99jh6MEJHKga1BjSYIXwFLTWsiA9df2.lACWAVC. f8lc7JJRDZC5xJZUdHGXEeSTuvesJUZjN9KD3xUX198jmKJjvG6BQxmh9qwjE0HAsjx26TvLyjSC JWK0bXhIFpsyyYgQzFqXx29ZbPCYRb6y12NL0.uolrNLOpVkxGEDtSIolJ4d05aEUS0JR1zLzjv6 zzMLFsJcDgqCPp387iHTeeimdDKL1nej4Xdwq3gSBAb0kl2Zdkye.9CM8Xw1KOdei4lWWLoJ8cir hi8pVr54B1.3yRukeTH1faKhNjfG.bfCY_Vi_gOuCGg9uWuC_KgTDsa6P_l9mm4FTWHTR_VhhuDQ TAxQtcETpFlvm91zWPmp672X9Pqv9Tc3Fcu4gpzSs2pZ2pLidHLUdXuj3ojslBayszrAN.JIdq2V vV_vTlE9y3L.c3_.QKBQceeqyQOh2wh8yYZlGqBxftmkBqb9dFQdom2HI6YBC5EYLdTDV1bn3zF4 OfQtrkODkBGVf9p0r2cjdFx8a3hBWo4TanF3pReMJSmq3YlWLAxX.fc0wctsVLZ96pjIpUqcJ1z6 6mmn.1vw_jdcWQndM5e2M6z8zvsj6_TsVVZVL.dUhqLNtJwN7FUIlHmR4NbmWzUPTryU4x35uIAp lMH1rf9KdjOi5QzBmg8bI1Bwo8jSjCdSkXGlOm1sVhQXcb1cZ3pSnz9db5.rT2uoieKqemjo.Xt0 NDnCPbl8tUmybgu7iddqCj4LWta3jdhQP2Iu5vbZz9nVAQURQ1u87CcYZn4X5DMYohtplNCOCr8t XCBCLoXeZd3l.U0j2wvQqZ3PqL8Ml2ASLaT8pr8ez4OAKNFIyaSo8.Doz2Cxh14BiP4sRksDqDdb 9oCm4raadP4BSSuAlKB56yvsKifOXxfy5Zwk_L4tEyS008wFZ9jSQzG01XS63SlW_4gfThJw2adx HB23kH5H85hWL.cBStcRxiqe98dsgFvRNDZNP..Xg3wFHaDy1WE_XTxrwRaE4Nce.mYfqaIhIRWY RDehXYEmNgS3jbDRWptyu3LE5vMAOMA8qoud4CjNCDvDSqqdZLRDHbnPvyrHmAwioP4MxKTWOZTi Qx2DW9Xx3gqXWzlFvPTCFyAMme2eOQoX0HOQVX.20ejAOFKozvvdBtMkBiElLejbJGzQvtm7ls6Q KG6ez3vo2k9nXRUc0eD.XMRKSiIvfyJRzWv.rElOonzCwFaM_IqMuoKW.UhbUCi1onUBMunL7w8N WeLtSPjvY68JUCKVwUa8.0Gm5a_VTbKioFfexqAIU2gerh.PCfHjnwW9CMTVhKwSrPh2CW0FaO8v XVSwxJlHVs6jQFDn2bHoyEZJzfLg3JealYkgNw.OwJ0dI4ttjO1i2dLEuvv_rUwenUpiwYinGvig Y9TMgY7Oz4bk2J1POat0Gt7GDdq.IIjv5y52lHaoTxZyfb5Ltt6l9SH4n X-Sonic-MF: X-Sonic-ID: 69d3b702-363b-43ab-b68b-0d0c699d1262 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 2 Apr 2026 18:24:45 +0000 Received: by hermes--production-gq1-6dfcf9f8b-ch4sw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6d7fda4883249c247700829d5e8b9e65; Thu, 02 Apr 2026 18:24:39 +0000 (UTC) Message-ID: Date: Thu, 2 Apr 2026 11:24:38 -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 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Uh, what's this? (PKGBASE implication) To: freebsd-hackers@freebsd.org, freebsd-pkgbase@freebsd.org, freebsd-pkg@freebsd.org References: <20260402205415.aa43b756e2b1036ab1fb9b9c@dec.sakura.ne.jp> <7b070db3-9540-41aa-8289-05cc386d3563@denninger.net> Content-Language: en-US From: Mark Millard Cc: Karl Denninger In-Reply-To: <7b070db3-9540-41aa-8289-05cc386d3563@denninger.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.25495 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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-Rspamd-Queue-Id: 4fmqyX29TMz3Sdv X-Spamd-Bar: ---- [This is basically a forward from freebsd-hackers@ to freebsd-pkgbase@ and freebsd-pkg@ . It seems to report a type of pkg handling problem for both port-packages and base-packages. It has the later reply that goes into more detail than the original message did.] On 4/2/26 09:08, Karl Denninger wrote: > On 4/2/2026 07:54, Tomoaki AOKI wrote: >> On Thu, 2 Apr 2026 07:41:21 -0400 >> Karl Denninger wrote: >> >>> I did not let this proceed as I really don't feel like having a mess to >>> un-mess.... >>> >>> [root@NewFS /home/karl]# uname -v >>> FreeBSD 14.4-STABLE #31 stable/14-n273840-e5ed09ffd592-dirty: Thu Mar 26 >>> 11:17:07 EDT 2026 >>> root@NewFS.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC >>> >>> [root@NewFS /home/karl]# pkg upgrade >>> Updating FreeBSD repository catalogue... >>> FreeBSD repository is up to date. >>> Updating FreeBSD-kmods repository catalogue... >>> FreeBSD-kmods repository is up to date. >>> All repositories are up to date. >>> Checking for upgrades (255 candidates): 100% >>> Processing candidates (255 candidates): 100% >>> The following 13 package(s) will be affected (of 0 checked): >>> >>> New packages to be INSTALLED: >>>         mysql84-client: 8.4.8 [FreeBSD] >>> >>> Installed packages to be UPGRADED: >>>         ffmpeg: 8.0.1_5,1 -> 8.1,1 [FreeBSD] >>>         harfbuzz: 13.1.1 -> 13.2.1 [FreeBSD] >>>         mpc: 1.3.1_1 -> 1.4.0 [FreeBSD] >>>         mysql80-client: 8.0.45 -> 8.0.45_1 [FreeBSD] >>>         nmap: 7.98_1 -> 7.99_1 [FreeBSD] >>>         openexr: 3.4.5 -> 3.4.8 [FreeBSD] >>>         perl5: 5.42.1 -> 5.42.2 [FreeBSD] >>> >>> Installed packages to be REINSTALLED: >>>         cacti-php83-1.2.30 [FreeBSD] (direct dependency changed: >>> mysql84-client) >>>         libass-0.17.4 [FreeBSD] (direct dependency changed: libunibreak) >>>         libv4l-1.23.0_5 [FreeBSD] (direct dependency changed: libudev-devd) >>>         libvdpau-1.5 [FreeBSD] (direct dependency changed: libXext) >>>         mpfr-4.2.2,1 [FreeBSD] (direct dependency changed: indexinfo) >>> >>> Number of packages to be installed: 1 >>> Number of packages to be upgraded: 7 >>> Number of packages to be reinstalled: 5 >>> >>> The process will require 108 MiB more space. >>> 84 MiB to be downloaded. >>> >>> Proceed with this action? [y/N]: >>> >>> Uh, that's a "no" :-) >>> >>> mysql84-client is going to shove things in the same place as mysql80, >>> which it also wants to upgrade the version of.  I also have the server >>> loaded; a prior "upgrade" attempt yesterday wanted to upgrade both of >>> those, but there are also several other dependencies (e.g. php modules) >>> which it DID NOT want to upgrade, and that's a potentially-serious >>> problem, and I'm also concerned about cacti which it wants to touch too. >>> >>> -- >>> Karl Denninger >>> karl@denninger.net >>> /The Market Ticker/ >>> /[S/MIME encrypted email preferred]/ >> See corresponding UPDATING entry dated 20260326. >> Stick with 80 or switch to 84. >> >> https://github.com/freebsd/freebsd-ports/blob/main/UPDATING#L60 >> >> But not sure if DEFAULT_VERSIONS in /etc/make.conf works >> on pre-built pkg upgrades. >> >> I myself don't use mysql (having client installed as an "automatic" >> depencencies of something, though), so not 100% sure it works OK or >> not, switching client alone possibly help. >> >> Client are more depended upon by others compared with server. >> >> Regards. > > Apologizes for the less-than-clear subject line, but this has > implications for PKGBASE which is why I put it here on the list. > > A "back-dependence" such as this, if you approve it, will abort because > the new version of the client (in this case) tries to install into an > existing location for the other version, which is already there and is > not being deleted first, and as a result it fails.  That operation is > non-atomic and thus if it hits something that the system needs you got > trouble (particularly if you didn't use bectl/beadm first!) as now you > have part of whatever you updated in place but not all of it, nor does > it roll it all back if any part of the install sequence fails. > > Pkg does not appear to have a good way to deal with this issue, and I > can come up with several instances in the past where a package has had > this issue (in particular when OpenSSL 1.x was in base, newer non-ABI- > compatible version(s) were in ports/packages, and you needed the newer > to compile something, although I've also had it bite me with some php > modules in the past.)  If the shared libraries get yanked out from under > an executable (e.g. they're upgraded to a new .so version) then the > other binaries will obviously not run. > > If that hits a "gotta have it" system-level binary then you've got a > broken system. > > I'm not sure there's a good way to deal with this with pkg not having > the capacity to be atomic in what it does -- that is, "all is good or > none commits." > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ -- === Mark Millard marklmi at yahoo.com