[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/46887: pkg_rolling-replace boost-libs-1.51.0 Can't open +CONTENTS akonadi-1.7.0nb1
The following reply was made to PR pkg/46887; it has been noted by GNATS.
From: David Holland <dholland-pbugs%netbsd.org@localhost>
Subject: Re: pkg/46887: pkg_rolling-replace boost-libs-1.51.0 Can't open
Date: Sun, 2 Sep 2012 03:21:01 +0000
On Sat, Sep 01, 2012 at 05:25:00PM +0000, davshao%gmail.com@localhost wrote:
> ===> Building binary package for boost-libs-1.51.0
> => Creating binary package /usr/pkgsrc/packages/All/boost-libs-1.51.0.tgz
> ===> Replacing for boost-libs-1.51.0
> WARNING: experimental target - DATA LOSS MAY OCCUR.
> Creating binary package: boost-libs-1.50.0
> Creating package /usr/pkgsrc/devel/boost-libs/work/boost-libs-1.50.0
> ===> Updating using binary package of boost-libs-1.51.0
> /usr/pkg/sbin/pkg_add -K /var/db/pkg -U -D
> pkg_add: Can't open +CONTENTS of depending package akonadi-1.7.0nb1
> pkg_add: 1 package addition failed
> *** Error code 1
obvious questions first:
- Did you actually have akonadi installed? If so, is it still
installed, or did pkg_rr remove it and then trip on itself? In either
of the latter cases, something's wrong with pkg_rr.
- Alternatively, have the contents of the file
/var/db/pkg/boost-libs-1.50.0/+REQUIRED_BY gotten out of sync with reality?
E.g. there might be packages listed there that don't exist or are
actually installed as different versions, or things like that. In this
case, do "pkg_admin rebuild-tree" and the nonsense should go away.
(Note that sometimes packages will be listed twice with the same
version, including after doing a rebuild-tree; this is wrong, more or
less, but normal and not cause for alarm.)
If pkg_add managed to remove the /var/db/pkg directory for the old
boost-libs (deinstalling the old version) without populating the new
one (installing the new version), so you now have no boost-libs
installed at all, you should be able to do "make install" in
devel/boost-libs; then do "pkg_admin rebuild-tree". Then tell pkg_rr
to explicitly rebuild akonadi, just in case.
- Another possibility is that /var/db/pkg/akonadi-1.7.0.nb1 exists
but does not contain a proper package directory; this sometimes
happens if pkg_delete gets interrupted or crashes when removing a
package. In this case, move the offending directory out of the way for
later analysis (or just delete it) and restart pkg_rr. You might want
to explicitly install and remove (or just install) akonadi afterwards
to make sure any bits previously left behind in /usr/pkg get cleaned
- Also, if the file exists and has weird permissions, that might be
the problem. Or if it exists but isn't a regular file, or contains
garbage, or whatever. In these cases, it's probably a good idea to
fsck your filesystem volume, just in case, then proceed as per the
The last case isn't real likely if you've seen the same problem on
more than one machine. In fact, at some level, none of these
situations are, so it's possible that none of the stuff in this
message will be useful...
David A. Holland
Main Index |
Thread Index |