перенесем обсуждение в 21812

*** This bug has been marked as a duplicate of bug 21812 ***

У нас ведь java-devel-default это он? Если да, то не вижу исправления

мы уже это вопрос обсуждали, я напомню:
-----------------------------------------
вкратце: 
* либо хотите чтобы все было автоматически,
и тогда линкуетесь с java-1.6.0-openjdk,
точнее с /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/*/*/libjvm.so

* либо вручную правите rpath на /usr/lib/jvm/java/jre/lib/arch/{client,server}/libjvm.so и вручную же фильтруете requires (я писал как)
-----------------------------------------
путь /usr/lib/jvm/java-1.6.0-sun-1.6.0.14
очевидно будет сломан при обновлении :(
если уже и писать что-то в rpath, то советую писать
/usr/lib/jvm/java-1.6.0-sun/jre/lib/i386/client,
и такую зависимость фильтровать вручную.
-------------------------------------
решил вам посоветовать
линковаться с java 1.6.0 openjdk.
это имеет то преимущество, что линковочный путь там определен
и не скачет от версии к версии.
java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server
на x86_64 client/*.so нет, там только server.
----------------------------------------------

(В ответ на комментарий №3)
> на x86_64 client/*.so нет, там только server.
значит, там cmake найдет server/*

(В ответ на комментарий №3)
> * либо вручную правите rpath на
> /usr/lib/jvm/java/jre/lib/arch/{client,server}/libjvm.so и вручную же
Это сделать можно, но зачем?
Если с client/libjvm.so никто линковаться не должен, то ее либо не должно быть в пакете, либо она должна лежать там, где ее никто не найдет. Если cmake находит именно ее, то наверняка он это делает правильно.

> фильтруете requires (я писал как)
не работает, т.к. нет provides для замены отфильтрованным requires

(В ответ на комментарий №3)
> если уже и писать что-то в rpath, то советую писать
> /usr/lib/jvm/java-1.6.0-sun/jre/lib/i386/client,
Ща попробую, посмотрю, что будет

(В ответ на комментарий №3)
> * либо хотите чтобы все было автоматически,
> и тогда линкуетесь с java-1.6.0-openjdk,
Это уже не автоматически. Автоматически -- это я пишу java-devel-default или еще нечто, что никогда не измениться, а мне ставят то, что нужно.

(В ответ на комментарий №3)
> если уже и писать что-то в rpath, то советую писать
> /usr/lib/jvm/java-1.6.0-sun/jre/lib/i386/client,
Он есть только в java-1.6.0-sun. Как его узнать автоматически имея уверенность, что это всегда точно он?

> и такую зависимость фильтровать вручную.
Какой requires добавлять вместо отфильтрованного?

(В ответ на комментарий №3)
> решил вам посоветовать
> линковаться с java 1.6.0 openjdk.
Ручше посоветуйте линковаться с java-devel-suggested ;-)

> Это уже не автоматически. Автоматически -- это я пишу java-devel-default или
> еще нечто, что никогда не измениться, а мне ставят то, что нужно.
Пишите java-devel-openjdk :)

in alt2

В provides /path/to/libjvm.so попали пустые скобки

и еще отсутствует макрос для /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so(SUNWprivate_1.1)

(В ответ на комментарий №13)
> /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so(SUNWprivate_1.1)
Может, в %_libjvmserver_sun_private_default эту строку?

Или какой-нибудь %_libjvmserver_sun_private_current ?

(В ответ на комментарий №14)
> (В ответ на комментарий №13)
> > /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so(SUNWprivate_1.1)
> Может, в %_libjvmserver_sun_private_default эту строку?

Не соображу. Зачем нужна эта строка?
Правильный Requires: должен проставиться автоматически findreq-ом,
по итогам rpath.
а в rpath надо пихать `dirname %_libjvmserver_sun_private_default`
я так себе представлял эту схему:
chrpath -r `dirname %_libjvmserver_sun_private_default` %buildroot/your/lib

(В ответ на комментарий №16)
> Правильный Requires: должен проставиться автоматически findreq-ом,
> по итогам rpath.
хрен там :-(
Проставляется
/usr/lib/jvm/java-1.5.0-sun-1.5.0.19/jre/lib/i386/client/libjvm.so(SUNWprivate_1.1)

Попробуй собрать мой soprano-backend-sesame, чтоб виднее стало

(В ответ на комментарий №16)
> я так себе представлял эту схему:
> chrpath -r `dirname %_libjvmserver_sun_private_default` %buildroot/your/lib
Я именно так и делал, но зависимость у пакета получается хреновая,
поэтому и подумал проставить вручную такой %_libjvmserver_sun_private, который содержит (SUNWprivate_1.1)

Попробуй собрать мой soprano-backend-sesame, чтоб не задавать лишних вопросов
Строку Requires: %_libjvmserver_sun_private_default можно закомментировать пока, чтоб не мешалась

Сергей, я извиняюсь что не сразу ответил,
был offline так как Покров и д.рожд. сыну (6 лет).
я посмотрел libsoprano-backend-sesame, как вы просили,
да, CanonPath в lib.req здесь играет плохую штуку :(
соответственно, любые другие симлинки не спасут и нужен фильтр.

Я добавил в спек фильтр, и он у меня собрался с нужными requires.
я запушил изменения к себе на git.alt.
тж. прилагаю diff

Created attachment 3995 [details]
тж. прилагаю diff

Дошли руки у меня до nepomuk. У меня после какого-то очередного 
обновления панель в dolphin с интегрированными nepomuk приблудами стала 
активной, можно было изменить комментарий и поставить файлу оценку, но 
ничего из этого не сохранялось.

$ nepomukserver
(Soprano::PluginManager) found no soprano plugin at  
"/usr/lib/soprano/libsoprano_sesame2backend.so"
$ ldd /usr/lib/soprano/libsoprano_sesame2backend.so
  libjvm.so => not found

При том, что этот самый libjvm.so есть в 
/usr/lib/jvm/jre/lib/i386/server/

Сделал:
$ ln -s /usr/lib/jvm/jre/lib/i386/server/libjvm.so /usr/lib/libjvm.so 

После этого, возможность выставлять метки и оценку работает

$ rpm -qa | grep java
java-1.6.0-sun-1.6.0.17-alt1
fonts-ttf-java-1.6.0-sun-1.6.0.17-alt1
java-1.6.0-sun-javaws-1.6.0.17-alt1
java-common-1.3.18-alt1
mozilla-plugin-java-1.6.0-sun-1.6.0.17-alt1
rpm-build-java-1.7.6-alt13

$ rpm -qa | grep nepomuk
libnepomukquery4-4.3.3-alt1.M51.1
libnepomukqueryclient4-4.3.3-alt1.M51.1

Еще покажите вывод от
rpm -q soprano-backend-sesame
и
rpm -q --requires soprano-backend-sesame | grep jvm

(В ответ на комментарий №21)
> $ ldd /usr/lib/soprano/libsoprano_sesame2backend.so
>   libjvm.so => not found
И у меня воспроизвелось после удаления java-1.6.0-sun-devel

$ rpm -q soprano-backend-sesame
soprano-backend-sesame-2.3.1-alt1
$ rpm -q --requires soprano-backend-sesame | grep jvm
/usr/lib/jvm/java/jre/lib/i386/server/libjvm.so(SUNWprivate_1.1)

Описание аналогичной проблемы в других дистрибутивах:
http://lists.opensuse.org/opensuse-bugs/2008-12/msg09478.html
https://bugs.launchpad.net/ubuntu/+source/soprano-backend-sesame/+bug/334186

Проблема понятна. Просто, не дорешили.

(В ответ на комментарий №26)
> Проблема понятна. Просто, не дорешили.

Торможу. В чем причина? 

остается ли путь /usr/lib/jvm/java/jre/lib/i386/server/libjvm.so
?

/usr/lib/jvm/java/jre/lib/i386/server/libjvm.so пропадает после удаления java-1.6.0-sun-devel-1.6.0.17-alt1
Нужно и остальных проверить на этот счет
$ l /usr/lib/jvm/java
ls: cannot access /usr/lib/jvm/java: No such file or directory

$rpm -qa| grep java
rpm-build-java-1.7.6-alt13
java-1.6.0-sun-1.6.0.17-alt1
javahelp2-2.0.05-alt2_1jpp5
mozilla-plugin-java-1.6.0-sun-1.6.0.17-alt1
gcc-java-common-1.4.14-alt1
tzdata-java-2009j-alt1
java-common-1.3.18-alt1
fonts-ttf-java-1.6.0-sun-1.6.0.17-alt1

Я извиняюсь, исправил ранее, но уехал и не успел сказать.

В чем исправление: перенес для совместимости текущие 
Provides: вида /usr/lib/jvm/java/jre/lib/i386/server/libjvm.so
в java-devel, 
а в jre внес правильные Provides: вида /usr/lib/jvm/jre/lib/i386/server/libjvm.so
со временем надо будет пересобрать сопрано с /usr/lib/jvm/jre... rpath,
и Provides: вида /usr/lib/jvm/java/... можно будет выкинуть.