The xapian-1.3.1 ebuild installs the binaries with "-1.3" suffix, which stops other packages from finding them. Names of the installed binaries: /usr/bin/xapian-tcpsrv-1.3 /usr/bin/xapian-replicate-server-1.3 /usr/bin/xapian-replicate-1.3 /usr/bin/xapian-progsrv-1.3 /usr/bin/xapian-metadata-1.3 /usr/bin/xapian-inspect-1.3 /usr/bin/xapian-delve-1.3 /usr/bin/xapian-config-1.3 /usr/bin/xapian-compact-1.3 /usr/bin/xapian-check-1.3 /usr/bin/simplesearch-1.3 /usr/bin/simpleindex-1.3 /usr/bin/simpleexpand-1.3 /usr/bin/quest-1.3 /usr/bin/copydatabase-1.3 Reproducible: Always Steps to Reproduce: 1. emerge =dev-libs/xapian-1.3.1 2. emerge =gnome-extra/zeitgeist-0.9.14 Actual Results: Zeitgeist fails during configure phase and complains that it can not find xapian-config Expected Results: Zeitgeist finds xapian-config and installs normally The fix is actually very simple, because it is described in Xapian configure.ac: dnl Disabled for stable release series. dnl Default to "-1.3"; for no suffix, specify: --program-suffix= test x"$program_suffix" != xNONE || program_suffix=-1.3 The solution that worked for me was to add --program-suffix= to the configure line like this: @@ -44,7 +44,7 @@ use chert || myconf="${myconf} --disable-backend-chert" use inmemory || myconf="${myconf} --disable-backend-inmemory" - myconf="${myconf} --enable-backend-remote" + myconf="${myconf} --enable-backend-remote --program-suffix=" econf $myconf }
(In reply to Nenad Peric from comment #0) > The xapian-1.3.1 ebuild installs the binaries with "-1.3" suffix, which > stops other packages from finding them. > > Names of the installed binaries: > /usr/bin/xapian-tcpsrv-1.3 > /usr/bin/xapian-replicate-server-1.3 > /usr/bin/xapian-replicate-1.3 > /usr/bin/xapian-progsrv-1.3 > /usr/bin/xapian-metadata-1.3 > /usr/bin/xapian-inspect-1.3 > /usr/bin/xapian-delve-1.3 > /usr/bin/xapian-config-1.3 > /usr/bin/xapian-compact-1.3 > /usr/bin/xapian-check-1.3 > /usr/bin/simplesearch-1.3 > /usr/bin/simpleindex-1.3 > /usr/bin/simpleexpand-1.3 > /usr/bin/quest-1.3 > /usr/bin/copydatabase-1.3 > > > Reproducible: Always > > Steps to Reproduce: > 1. emerge =dev-libs/xapian-1.3.1 > 2. emerge =gnome-extra/zeitgeist-0.9.14 > > Actual Results: > Zeitgeist fails during configure phase and complains that it can not find > xapian-config > > Expected Results: > Zeitgeist finds xapian-config and installs normally > > The fix is actually very simple, because it is described in Xapian > configure.ac: > > dnl Disabled for stable release series. > dnl Default to "-1.3"; for no suffix, specify: --program-suffix= > test x"$program_suffix" != xNONE || program_suffix=-1.3 > > The solution that worked for me was to add --program-suffix= to the > configure line like this: > > @@ -44,7 +44,7 @@ > use chert || myconf="${myconf} --disable-backend-chert" > use inmemory || myconf="${myconf} --disable-backend-inmemory" > > - myconf="${myconf} --enable-backend-remote" > + myconf="${myconf} --enable-backend-remote --program-suffix=" > > econf $myconf > } Yep, this will be fixed soon. I had to stop in the middle of working on the xapian suite last night ... to sleep :)
--- ./ChangeLog +++ ./ChangeLog @@ -4,0 +5,6 @@ +*xapian-1.3.1-r1 (06 Aug 2013) + + 06 Aug 2013; Anthony G. Basile <blueness@gentoo.org> +xapian-1.3.1-r1.ebuild, + -xapian-1.3.1.ebuild: + Fix program suffix, bug #479910 +
This upgrade makes app-misc/recoll dead.
(In reply to Gerard van Vuuren from comment #3) > This upgrade makes app-misc/recoll dead. Is this a problem with this upgrade or does recoll need an update to comply? In the former case this bug is not resolved; in the latter case, this bug should be marked as FIXED again and we will probably want to file a bug against app-misc/recoll then. Too busy processing two weeks of mails now; but assuming good faith, reopened. If no response or idea, then I'll try to get back to this; as soon as possible.
(In reply to Tom Wijsman (TomWij) from comment #4) > (In reply to Gerard van Vuuren from comment #3) > > This upgrade makes app-misc/recoll dead. > > Is this a problem with this upgrade or does recoll need an update to comply? > > In the former case this bug is not resolved; in the latter case, this bug > should be marked as FIXED again and we will probably want to file a bug > against app-misc/recoll then. > > Too busy processing two weeks of mails now; but assuming good faith, > reopened. > If no response or idea, then I'll try to get back to this; as soon as > possible. This is a different issue than the original. You should open a new one regarding this issue.
*** Bug 479938 has been marked as a duplicate of this bug. ***
