From owner-freebsd-ports@freebsd.org Tue May 22 21:58:44 2018 Return-Path: Delivered-To: freebsd-ports@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 26EC0EB0FFA for ; Tue, 22 May 2018 21:58:44 +0000 (UTC) (envelope-from SRS0=CMOo=IJ=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB2CF6AF61 for ; Tue, 22 May 2018 21:58:43 +0000 (UTC) (envelope-from SRS0=CMOo=IJ=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id F2D3128416 for ; Tue, 22 May 2018 23:58:35 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 1204228412 for ; Tue, 22 May 2018 23:58:35 +0200 (CEST) To: freebsd-ports@freebsd.org From: Miroslav Lachman <000.fbsd@quip.cz> Subject: unreliable pkg upgrades Message-ID: Date: Tue, 22 May 2018 23:58:34 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 21:58:44 -0000 Am I the only one seeing occasional unreliable pkg upgrades? I think changes in package name or ports origin should be better handled by pkg tools. For example, we have php-composer installed on many of our machines. The ports was flavorized, ports origin is the same, but pkg reports php-composer as orphaned. pkg upgrade just ignores php-composer: root@jahoda ~/# pkg upgrade Updating codelab repository catalogue... codelab repository is up to date. All repositories are up to date. Checking for upgrades (0 candidates): 100% Processing candidates (0 candidates): 100% Checking integrity... done (0 conflicting) Your packages are up to date. But if I tell the pkg that I want to upgrade devel/php-composer it will do the right thing root@jahoda ~/# pkg upgrade devel/php-composer Updating codelab repository catalogue... codelab repository is up to date. All repositories are up to date. The following 1 package(s) will be affected (of 0 checked): New packages to be INSTALLED: php71-composer: 1.6.3 Number of packages to be installed: 1 The process will require 2 MiB more space. 380 KiB to be downloaded. Proceed with this action? [y/N]: y [1/1] Fetching php71-composer-1.6.3.txz: 100% 380 KiB 389.3kB/s 00:01 Checking integrity... done (1 conflicting) - php71-composer-1.6.3 conflicts with php-composer-1.6.2 on /usr/local/bin/composer Checking integrity... done (0 conflicting) Conflicts with the existing packages have been found. One more solver iteration is needed to resolve them. The following 2 package(s) will be affected (of 0 checked): Installed packages to be REMOVED: php-composer-1.6.2 New packages to be INSTALLED: php71-composer: 1.6.3 Number of packages to be removed: 1 Number of packages to be installed: 1 Proceed with this action? [y/N]: y [1/2] Deinstalling php-composer-1.6.2... [1/2] Deleting files for php-composer-1.6.2: 100% [2/2] Installing php71-composer-1.6.3... [2/2] Extracting php71-composer-1.6.3: 100% Why it is not handled automatically like in other OSes? That's the reason we are still not using Ansible for mass pkg upgrades, because we must carefully watch each and every pkg upgrade run. What it will do and what it refuse to do without manual intervention. Miroslav Lachman PS: we are using own repository built with poudriere