pkgsrc-Bugs archive

[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 <>
Subject: Re: pkg/46887: pkg_rolling-replace boost-libs-1.51.0 Can't open
 +CONTENTS akonadi-1.7.0nb1
Date: Sun, 2 Sep 2012 03:21:01 +0000

 On Sat, Sep 01, 2012 at 05:25:00PM +0000, 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
 previous paragraph.
 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

Home | Main Index | Thread Index | Old Index