pkg_add errors

Dominic Fandrey kamikaze at
Wed May 27 16:43:51 UTC 2009

During my last run of 'pkg_upgrade -a', cups-client forgot to install
the library, 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.

More information about the freebsd-ports mailing list