Date: Wed, 27 May 2009 18:43:36 +0200 From: Dominic Fandrey <kamikaze@bsdforen.de> To: freebsd-ports@freebsd.org Subject: pkg_add errors Message-ID: <4A1D6DB8.40209@bsdforen.de>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A1D6DB8.40209>