Digikam 0.8+ fails when the album is on an NFS mounted volume, because sqlite doesn't work with databases over NFS3. The Digikam authors have implemented a workaround that keeps the database in ~/.kde instead of the album directory. This patch enables that workaround when the nfs USE flag is set.
Ack! Sending the patch as an attachment gives a server error. Here is is --- digikam-0.8.1.ebuild.orig 2006-02-12 10:05:51.760415000 +0000 +++ digikam-0.8.1.ebuild 2006-02-12 11:59:20.439089000 +0000 @@ -16,7 +16,7 @@ SLOT="0" LICENSE="GPL-2" KEYWORDS="~alpha ~amd64 ~ia64 ~ppc ~x86" -IUSE="" +IUSE="nfs" DEPEND=">=media-libs/libgphoto2-2 >=media-libs/libkexif-0.2.1 @@ -34,6 +34,7 @@ } src_compile(){ + EXTRA_ECONF="$EXTRA_ECONF $(use_enable nfs nfs-hack)" kde_src_compile cd ${WORKDIR}/${P_POC} kde_src_compile
Actually you should never change EXTRA_ECONF. Use myconf variable instead.
OK, I've changed that line to myconf=$(use_enable nfs nfs-hack) Out of interest, why not use EXTRA_ECONF? I used it here because I'd used it on the command line first to check that it worked as I needed. Using myconf works just as well.
Well, I'm not fond of it, but you're the one using it. The proper solution would be to use a real db. As soon as someone cries because of facing file locking issues, I'll remove the use flag again.
.
Unfortunately, there's no option to use anything but sqlite. I don't see why file locking should be an issue with the nfs flag, it prevents the database being stored on an NFS volume. It may well be a file locking problem that causes sqlite to fail over NFS.
