From owner-freebsd-ports@FreeBSD.ORG Wed May 27 16:43:50 2009 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F34C106571D for ; Wed, 27 May 2009 16:43:50 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 392978FC08 for ; Wed, 27 May 2009 16:43:50 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (unknown [88.130.192.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id DEB1C8A0194; Wed, 27 May 2009 18:43:48 +0200 (CEST) Message-ID: <4A1D6DB8.40209@bsdforen.de> Date: Wed, 27 May 2009 18:43:36 +0200 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: freebsd-ports@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: pkg_add errors X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 16:43:51 -0000 During my last run of 'pkg_upgrade -a', cups-client forgot to install the library libcups.so.2, which I fortunately recognized due to my routine of running pkg_libchk after every package/port upgrade. Running 'pkg_upgrade cups-client' fixed that problem. The interesting part is, that the reinstallation of cups-client was done from the same package. So either pkg_add, tar or the file system were to blame, because the package is without fault. I expect that this unreliability of pkg_add (or the underlying systems) has a severe impact on my further development of pkg_upgrade. A simple check whether the package has been fully installed using 'pkg_info -g' is not a solution, because many packages (e.g. scribus or gstreamer-plugins-bad) come with faulty PLISTs, so 'pkg_info -g' is not a reliable way to check for a successful install. Maintainers have successfully ignored my bitching about broken PLISTs for years, so I cannot expect this to be solved upstream. The problem I face is that there are cases when a package installs incompletely. I can detect this and attempt a reinstall or even a redownload and reinstall. But what if the install is still broken? Terminate pkg_upgrade with an error? That does not look like an option to me, because it would quit whenever a package with a broken PLIST is encountered and rendered almost useless by this. At least for as long as committers accept ports with broken PLISTs. What I need is a solution that is right most of the time, does not cause pkg_upgrade to stop and can be easily redeemed afterwards, if it hasn't been right after all. I have found such a solution for the conflict handling (existing packages take preference, so e.g. boost-python will be accepted as a dependency instead of boost, or a2ps-a4 instead of a2ps-letter). If the default solution was wrong the packages can easily be exchanged using -o or -C. I need something similar for the incomplete package problem. Should pkg_upgrade create a summary of apparently broken packages that have been installed? Should it bail out (and break with every package that has a broken plist)? Should it perform library checks and try to auto fix them? My preference would be to rely on 'pkg_info -g', but that would require all committers to run extensive checks before committing changes to the ports tree. Miwi has always done this and more than once revealed PLIST problems of my ports to me. But I wonder whether it is really sensible to ask committers to test everything on a Tinderbox (preferably on several platforms) before committing changes to the ports tree.