From owner-freebsd-hackers@freebsd.org Mon Mar 11 09:52:02 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91B4B153A676 for ; Mon, 11 Mar 2019 09:52:02 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E6508DDCB for ; Mon, 11 Mar 2019 09:52:02 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: matthew/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id DDD2613337 for ; Mon, 11 Mar 2019 09:52:01 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from leaf.local (unknown [88.212.184.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id BB60215BF9 for ; Mon, 11 Mar 2019 09:52:00 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk/BB60215BF9; dkim=none; dkim-atps=neutral From: Matthew Seaman Subject: Re: Upgrading discontinued ports To: freebsd-hackers@freebsd.org References: <3445abe8-11a9-5810-b244-87c0d2751dd0@erdgeist.org> <03fcd350-56b3-9724-1fdc-491a5228e2ac@erdgeist.org> Message-ID: <418648ad-5f10-1cfb-1f2a-1809a7a5e959@FreeBSD.org> Date: Mon, 11 Mar 2019 09:52:00 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <03fcd350-56b3-9724-1fdc-491a5228e2ac@erdgeist.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 2E6508DDCB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 09:52:02 -0000 On 11/03/2019 06:48, Dirk Engling wrote: > On 11.03.19 04:56, Robert Ayrapetyan wrote: > >> Are you sure you've used a "force" flag, e.g. "pkg-static upgrade >> -f"? > Yes. But all that does is force reinstall installed packages. However > the old package just isn't in the pkg repo anymore, so there's nothing > to re-install. pkg(8) does know about successor packages for many of these cases, but only for what is mentioned in MOVED. Unfortunately, in the specific case of upgrading from php56 to php72, pkg(8) has no idea of the equivalence between php56-foo and php72-foo packages. All it knows is that php56-foo and php72-foo conflict on installation, so when you install an updated php application compiled to depend on php72 modules it will install the php72 dependencies for that application, replacing the php56 equivalents. If you've still got php56 modules left over, then one of two things has happened. Either you've installed a php56 module directly, because (for instance) it was needed by some not-packaged PHP application you're running, or else you've still got an old version of some PHP app package installed that still depends on those php56 modules. It's usually fairly easy to sort either of those two situations out, but it does require manual intervention. The best approach here is to run: pkg version -vRL= whenever you're doing an upgrade with a significant change to something with a big module library (PHP, perl, python, etc). This should highlight anything you have installed with no corresponding package in the repo, so that you can take appropriate action. Cheers, Matthew