From nobody Tue Oct 04 16:25:53 2022 X-Original-To: bugs@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 4Mhjk95PLFz4fC1Q for ; Tue, 4 Oct 2022 16:25:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mhjk94MVPz43nr for ; Tue, 4 Oct 2022 16:25:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Mhjk93QLQzcqZ for ; Tue, 4 Oct 2022 16:25:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 294GPro2081408 for ; Tue, 4 Oct 2022 16:25:53 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 294GPrtA081407 for bugs@FreeBSD.org; Tue, 4 Oct 2022 16:25:53 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 263879] pkgbase removes critical etc files upon upgrade Date: Tue, 04 Oct 2022 16:25:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: markj@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664900753; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qd8ZIakddCWFseRVeapg5KDZafGMEBZaSaXWw1fLk14=; b=LYf+GFLCEosjUtidLGng2bU6omFGpfF2g8vUzXYysPf8sfFmAAa+B7zvnZDLFHgg5KmsvY GM110KTEMcgHAKF51T4ve3p2GSp9UJWIDXZ+s5Q/vkEwGXMNCr7DLzFWOyngBeh4VuLzw2 EEpyXzc+s/MSqmLBCq1aYFSniwv4BdnnRZ6F2JSmwRLdXSr5UtolZptlZSamIbRCG08Mq+ oxkfvBfCjv8/7uoxgk6hkzEPnn4k2vcelAHQIfXOe+b8T2+vwJEtHd4d5nL1+8VFVYh0qk jFbXy7xwkyZBFkcGWF72C0Ft5yCcKLxmMUHiHlT6iUPKQbqW+wRfuWNhwixTNQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664900753; a=rsa-sha256; cv=none; b=nHI8mj/mkYcR7lT08Oi7ndJoaJ3U02BJu11wlOdGXgm39hZ6+bq4WQ3GDrk07AByUkSoV/ kZ92yzAQGQ14yvIZge/5OD8x4zExb4sHtTknnKfZDhNK0fn/JlLpLI4U1yXDj6VS274JzA FPIjAhFz8ttdDcHCT872WVCX6Db7kdl89SW8YdAZlIpKj5yp4o1DLkzDMFEKZhXwYQeSWF 7UYRVo8eP+KOyOjqP/0g01FWbeXzzHj1mbLMHBQ0gnIFfH67AFbs/M526546wkWwr67VD0 C1es3nJr4UVvFNd6r3Sd5MjcFi9ltJ2ngB4rmd1FBvxPVD1i+DEhXZe837cyyA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263879 --- Comment #4 from Mark Johnston --- I spent some time reading the libpkg job scheduler and I think I see part of the problem, but I'm not sure yet how to fix it. Basically, upon an upgrade I get a conflict on /etc/termcap.small between FreeBSD-runtime(local) and FreeBSD-utilities(remote). When handling the conflict, pkg decides to split the upgrade of -runtime into separate uninst= all and install jobs, which wipes my /etc files. But, obviously we can avoid t= he conflict by simply upgrading -runtime before -utilities; the split is not needed. And, pkg schedules the uninstall/install of -runtime back-to-back anyway, so it's no different from an upgrade. After pkg has figured out which jobs (i.e. package installs/upgrades/remova= ls) it will execute, it assigns priorities to determine the execution order. T= his happens in pkg_jobs_set_priorities(). If there's a conflict on a package b= eing deleted as part of an upgrade, pkg bumps the priorities of both the deletion and the addition jobs: 770 if (rit->priority >=3D req->items[1]->priority) {=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 771 pkg_jobs_update_universe_item_priority(universe, req->items[1],=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 772 rit->priority + 1, PKG_PRIORITY_UPDATE_CONFLICT);=20= =20=20=20=20=20=20=20=20=20 773 /*=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 774 * Update priorities for a remote part as well=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 775 */=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 776 pkg_jobs_update_universe_item_priority(universe, req->items[0],=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 777 req->items[0]->priority, PKG_PRIORITY_UPDATE_REQUEST);= =20=20=20=20=20 778 } pkg_jobs_update_universe_item_priority() recursively updates the priorities= of dependent jobs. However, it also has this check which I do not quite understand: 668 if ((item->next !=3D NULL || item->prev !=3D NULL) &&= =20=20=20=20=20=20=20=20=20=20 669 it->pkg->type !=3D PKG_INSTALLED &&=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 670 (type =3D=3D PKG_PRIORITY_UPDATE_CONFLICT ||=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 671 type =3D=3D PKG_PRIORITY_UPDATE_DELETE)) {=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 672 /*=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 673 * We do not update priority of a remote part = of conflict, as we know=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 674 * that remote packages should not contain conflicts (they should be=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 675 * resolved in request prior to calling of this function)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 676 */=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 677 pkg_debug(2, "skip update priority for %s-%s",= =20=20=20=20=20 678 it->pkg->uid, it->pkg->digest);=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 679 continue;=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 680 } In my case, it causes installation of the remote FreeBSD-runtime to have lo= wer priority than removal of the local FreeBSD-runtime package. This causes pk= g to split the job. Commenting out this block "fixes" my problem, but I can't t= ell if it actually affects correctness of the code, or if it's just an optimization, or... BTW, this behaviour is highly dependent on the order in which packages are loaded into various lists. If I fetch packages first, then cancel the upgr= ade, then try to upgrade again, I get different behaviour from the job scheduler= .=20 So it's not too surprising that others may not observe the problem. What's an example of an upgrade where a package really does need to be spli= t?=20 Consider two packages p1, p2 with files a and b respectively, and suppose t= hat new versions of those packages switch ownership, so p1 contains b and p2 contains a. Then to upgrade, we have to uninstall one of p1 or p2, upgrade= the other, then install the missing package. This situation can arise in the b= ase system, so how do we handle the case where two critical pkgbase packages are entangled this way? --=20 You are receiving this mail because: You are the assignee for the bug.=