(В ответ на комментарий №0)
> Так как пакет gst-plugins-base не провайдит своих библиотек они не видны ни
> ldconfig
1. Какое отношение провайды имеют к ldconfig?
2. Зачем ldconfig знать о непубличных библиотеках?

> ни таким пакетам, как opera, требующим libgstvorbis.so и пачку других.
Они их требуют с путём или без?

%_libdir/gstreamer-0.10/*.so это плагины не имеющие к раздиляемым библиотекам никакого отношения и провайдить в виде "libgstvorbis.so" пакет их никогда не будет

(В ответ на комментарий №1)
> (В ответ на комментарий №0)
> > Так как пакет gst-plugins-base не провайдит своих библиотек они не видны ни
> > ldconfig
> 1. Какое отношение провайды имеют к ldconfig?
> 2. Зачем ldconfig знать о непубличных библиотеках?
Сорри, фигню сморозил.
 
> > ни таким пакетам, как opera, требующим libgstvorbis.so и пачку других.
> Они их требуют с путём или без?
Без. В виде 

  libgstvorbis.so

(В ответ на комментарий №2)
> %_libdir/gstreamer-0.10/*.so это плагины не имеющие к раздиляемым библиотекам
> никакого отношения и провайдить в виде "libgstvorbis.so" пакет их никогда не
> будет
А в opera эти библиотеки используются как разделяемые. Так что отношение как раз имеет.

Кстати, также нужно провайдить библиотеки для 
gst-plugins-boot

Сорри, не gst-plugins-boot, а gst-plugins-good

(В ответ на комментарий №4)
> А в opera эти библиотеки используются как разделяемые.
Показывай доказательства.

(В ответ на комментарий №6)
> (В ответ на комментарий №4)
> > А в opera эти библиотеки используются как разделяемые.
> Показывай доказательства.
Мда, проверил через ldd, не линкуется напрямую. По видимому, подключает через libdl. Но в opera...rpm есть Requires этих библиотек. Как в таком случае поступать?

(В ответ на комментарий №7)
> > > А в opera эти библиотеки используются как разделяемые.
> > Показывай доказательства.
> Мда, проверил через ldd, не линкуется напрямую.
Достаточно было прочитать месячной давности обсуждение этого вопроса в sisyphus@.

> Но в opera...rpm есть Requires этих библиотек. Как в таком случае
> поступать?
Писать разработчикам, как и предлагал aen@ месяц назад.

(В ответ на комментарий №8)
> > Но в opera...rpm есть Requires этих библиотек. Как в таком случае
> > поступать?
> Писать разработчикам, как и предлагал aen@ месяц назад.
В SUSE и FC библиотеки провайдятся:
(SUSE) http://rpmfind.net//linux/RPM/opensuse/factory/i586/gstreamer-0_10-plugins-base-0.10.29-1.6.i586.html
(Fedora Core) http://rpmfind.net//linux/RPM/fedora/devel/rawhide/i386/gstreamer-plugins-base-0.10.29-1.fc14.i686.html

Там дураки сидят?

еще какие ибо это не библиотеки

http://lists.altlinux.org/pipermail/sisyphus/2010-June/348008.html

Кому надо, пусть пишут в Opera, что они собирают кривые пакеты.

Вдогонку:

$ rpmpeek Download/opera-10.60-6386.x86_64.rpm find . -type f -exec eu-readelf -a '{}' ';' 2>/dev/null | grep NEEDED | sort -u
  NEEDED            Shared library: [libatk-1.0.so.0]
  NEEDED            Shared library: [libcairo.so.2]
  NEEDED            Shared library: [libc.so.6]
  NEEDED            Shared library: [libdl.so.2]
  NEEDED            Shared library: [libfontconfig.so.1]
  NEEDED            Shared library: [libfreetype.so.6]
  NEEDED            Shared library: [libgcc_s.so.1]
  NEEDED            Shared library: [libgdk_pixbuf-2.0.so.0]
  NEEDED            Shared library: [libgdk-x11-2.0.so.0]
  NEEDED            Shared library: [libglib-2.0.so.0]
  NEEDED            Shared library: [libgmodule-2.0.so.0]
  NEEDED            Shared library: [libgobject-2.0.so.0]
  NEEDED            Shared library: [libgstbase-0.10.so.0]
  NEEDED            Shared library: [libgstreamer-0.10.so.0]
  NEEDED            Shared library: [libgstvideo-0.10.so.0]
  NEEDED            Shared library: [libgthread-2.0.so.0]
  NEEDED            Shared library: [libgtk-x11-2.0.so.0]
  NEEDED            Shared library: [libICE.so.6]
  NEEDED            Shared library: [libkdecore.so.5]
  NEEDED            Shared library: [libkdeui.so.5]
  NEEDED            Shared library: [libkio.so.5]
  NEEDED            Shared library: [libm.so.6]
  NEEDED            Shared library: [libpango-1.0.so.0]
  NEEDED            Shared library: [libpangocairo-1.0.so.0]
  NEEDED            Shared library: [libpthread.so.0]
  NEEDED            Shared library: [libQtCore.so.4]
  NEEDED            Shared library: [libQtGui.so.4]
  NEEDED            Shared library: [librt.so.1]
  NEEDED            Shared library: [libSM.so.6]
  NEEDED            Shared library: [libstdc++.so.6]
  NEEDED            Shared library: [libX11.so.6]
  NEEDED            Shared library: [libXext.so.6]
  NEEDED            Shared library: [libXft.so.2]
  NEEDED            Shared library: [libxml2.so.2]
  NEEDED            Shared library: [libXrender.so.1]
  NEEDED            Shared library: [libXt.so.6]
  NEEDED            Shared library: [libz.so.1]

Это самодеятельность криворуких опероидов.

*** Bug 23709 has been marked as a duplicate of this bug. ***

(In reply to comment #7)
> (В ответ на комментарий №6)
> > (В ответ на комментарий №4)
> > > А в opera эти библиотеки используются как разделяемые.
> > Показывай доказательства.
> Мда, проверил через ldd, не линкуется напрямую. По видимому, подключает через
> libdl. Но в opera...rpm есть Requires этих библиотек. Как в таком случае
> поступать?

Кто-нибудь знает, как на самом деле opera использует эти файлы (если вообще использует)?

Подозреваю, что использует оно их как плагины gst через libgst*

(In reply to comment #15)
> Подозреваю, что использует оно их как плагины gst через libgst*

Другого варианта не остаётся:

$ rpmquery -pR opera-10.60-6386.x86_64.rpm |sed -n 's/^\(libgst[^.]*\)\.so(.*/\1/p'
libgstautodetect
libgstogg
libgsttheora
libgstvorbis
libgstwavparse

$ rpmpeek opera-10.60-6386.x86_64.rpm find -type f -exec fgrep libgst '{}' ';'
Binary file ./usr/lib/opera/gstreamer/plugins/libgstoperamatroska.so matches
Binary file ./usr/lib/opera/gstreamer/plugins/libgstoperavp8.so matches

$ rpmpeek opera-10.60-6386.x86_64.rpm find -type f -execdir eu-readelf -d '{}' ';' 2>/dev/null | fgrep libgst | sort -u
  NEEDED            Shared library: [libgstbase-0.10.so.0]
  NEEDED            Shared library: [libgstreamer-0.10.so.0]
  NEEDED            Shared library: [libgstvideo-0.10.so.0]

(In reply to comment #16)
> $ rpmpeek opera-10.60-6386.x86_64.rpm find -type f -execdir eu-readelf -d '{}'
> ';' 2>/dev/null | fgrep libgst | sort -u
>   NEEDED            Shared library: [libgstbase-0.10.so.0]
>   NEEDED            Shared library: [libgstreamer-0.10.so.0]
>   NEEDED            Shared library: [libgstvideo-0.10.so.0]

На библиотеки, с которыми есть линковка, у opera зависимостей нет, зато есть зависимости на плагины, с которыми никакой линковки быть не может.  Массаракш!

http://my.opera.com/russian/forums/topic.dml?id=593032&t=1278859240&page=2#comment6184462

http://fly.osdn.org.ua/~drool/opera/10.60/

http://lists.altlinux.org/pipermail/community/2010-July/664805.html

(В ответ на комментарий №18)
> http://my.opera.com/russian/forums/topic.dml?id=593032&t=1278859240&page=2#comment6184462

Спасибо. Передай Шпанькову привет и скажи, что не надо его некомпетентность в вопросе о разделяемых библиотеках компенсировать наездами на якобы оригинальность ALT Linux. :)

(В ответ на комментарий №19)
> Спасибо.

Да не за что.

> Передай Шпанькову привет и скажи, что не надо его некомпетентность в
> вопросе о разделяемых библиотеках компенсировать наездами на якобы
> оригинальность ALT Linux. :)

Андрей, я никогда не любил служить ретранслятором или прокладкой между двуся концами провода ;) Сам и скажи.

(В ответ на комментарий №20)
> Андрей, я никогда не любил служить ретранслятором или прокладкой между двуся
> концами провода ;) Сам и скажи.
Я не фанат Opera, чтобы терять время на регистрацию в их форуме и на разъяснение очевидных вещей.

Вообще, не плохо бы иметь механизм выявления зависимостей на gst-plugins-* кроме эмпирического.

(В ответ на комментарий №21)
> (В ответ на комментарий №20)
> > Андрей, я никогда не любил служить ретранслятором или прокладкой между двуся
> > концами провода ;) Сам и скажи.
> Я не фанат Opera, чтобы терять время на регистрацию в их форуме и на
> разъяснение очевидных вещей.

Андрей, я тоже не фанат AltLinux, но мне зарегистрироваться не в лом - у меня нет мании величия.

Впрочем, регистрироваться и не нужно. Я ещё в четверг отправил все контакты вашим ребятам и получил обещание от Алексея, что кто-нибудь из Альтов свяжется с нами. Пока тишина полная. Также замечу, что во внутреннем обсуждении проблемы в нашей BTS уважения к разработчикам AltLinux гораздо больше, чем у вас. Думаю, у вас пока нет особого повода ставить себя выше других.

А оригинальность AltLinux подтверждает хотя бы данная проблема.

(In reply to comment #23)
> Я ещё в четверг отправил все контакты
> вашим ребятам и получил обещание от Алексея, что кто-нибудь из Альтов свяжется
> с нами. Пока тишина полная.

Проблема вашей сборки (opera-10.60-6386.x86_64.rpm) не только в том, что она не соответствует нашей policy (нет необходимых зависимостей на слинкованные библиотеки, есть зависимости на плагины в недопустимой форме), что не удивительно, ибо её собирали в другой среде и для другой среды.

Дополнительная сложность заключется в том, что по форме и содержанию opera-10.60-6386.x86_64.rpm далёкому от opera человеку не очевидно, действительно ли там используются вышеупомянутые 5 gst-плагинов, или это какой-то атавизм.  Пока этот вопрос не разъяснится, к специалистам обращаться рано.  К сожалению, выяснение подобных вопросов существенно сложнее в том случае, когда софт поставляется без исходного кода.

(In reply to comment #22)
> Вообще, не плохо бы иметь механизм выявления зависимостей на gst-plugins-*
> кроме эмпирического.

Какие есть варианты?
И, кстати, как принято указывать зависимости на эти плагины сейчас?

(В ответ на комментарий №24)

> Дополнительная сложность заключется в том, что по форме и содержанию
> opera-10.60-6386.x86_64.rpm далёкому от opera человеку не очевидно,
> действительно ли там используются вышеупомянутые 5 gst-плагинов, или это
> какой-то атавизм.  Пока этот вопрос не разъяснится, к специалистам обращаться
> рано.  К сожалению, выяснение подобных вопросов существенно сложнее в том
> случае, когда софт поставляется без исходного кода.
При чём тут исходный код? ;)
Это с каких пор для сборки RPM-пакета стали нужны исходники?
Данные библиотеки нужны для полноценной поддержки спецификаций HTML5 в Linux-версиях браузера Opera. Об этом я и на форуме писал, да и что мешает спросить напрямую у наших разработчиков? Все явки и пароли известны. Было бы желание решить проблему.

(In reply to comment #26)
> (В ответ на комментарий №24)
> 
> > Дополнительная сложность заключется в том, что по форме и содержанию
> > opera-10.60-6386.x86_64.rpm далёкому от opera человеку не очевидно,
> > действительно ли там используются вышеупомянутые 5 gst-плагинов, или это
> > какой-то атавизм.  Пока этот вопрос не разъяснится, к специалистам обращаться
> > рано.  К сожалению, выяснение подобных вопросов существенно сложнее в том
> > случае, когда софт поставляется без исходного кода.
> При чём тут исходный код? ;)

По исходному коду проще понять, что на самом деле нужно программе. :)

> Это с каких пор для сборки RPM-пакета стали нужны исходники?

Для сборки как таковой исходники не нужны, и, насколько я понимаю, Геннадий это продемонстрировал.  Но вот для правильной сборки полезно знать, что нужно упаковываемой программе.

> Данные библиотеки нужны для полноценной поддержки спецификаций

Извините, но gst-плагины -- это не библиотеки.  С ними нет разумного способа слинковаться, как с библиотеками, их даже не принято загружать динамически напрямую с помощью dlopen(3).  Для того, чтобы с ними работать, в _библиотеках_ libgst* (зависимостей на которые у вас в пакете почему-то нет, хотя при сборке в среде ALT Linux они возникли бы автоматически по факту линковки) есть соответствующий API.  Без исходного кода или хотя бы документации не очевидно, каким именно образом opera загружает 5 вышеупомянутых gst-плагинов.

(В ответ на комментарий №27)
> (In reply to comment #26)
> > (В ответ на комментарий №24)
> > 
> > > Дополнительная сложность заключется в том, что по форме и содержанию
> > > opera-10.60-6386.x86_64.rpm далёкому от opera человеку не очевидно,
> > > действительно ли там используются вышеупомянутые 5 gst-плагинов, или это
> > > какой-то атавизм.  Пока этот вопрос не разъяснится, к специалистам обращаться
> > > рано.  К сожалению, выяснение подобных вопросов существенно сложнее в том
> > > случае, когда софт поставляется без исходного кода.
> > При чём тут исходный код? ;)
> 
> По исходному коду проще понять, что на самом деле нужно программе. :)

Так вы спросите! Мы ж не партизаны на допросе - всё расскажем ;)

> 
> > Это с каких пор для сборки RPM-пакета стали нужны исходники?
> 
> Для сборки как таковой исходники не нужны, и, насколько я понимаю, Геннадий это
> продемонстрировал.  Но вот для правильной сборки полезно знать, что нужно
> упаковываемой программе.
> 
> > Данные библиотеки нужны для полноценной поддержки спецификаций
> 
> Извините, но gst-плагины -- это не библиотеки.  С ними нет разумного способа
> слинковаться, как с библиотеками, их даже не принято загружать динамически
> напрямую с помощью dlopen(3).  Для того, чтобы с ними работать, в _библиотеках_
> libgst* (зависимостей на которые у вас в пакете почему-то нет, хотя при сборке
> в среде ALT Linux они возникли бы автоматически по факту линковки) есть
> соответствующий API.  Без исходного кода или хотя бы документации не очевидно,
> каким именно образом opera загружает 5 вышеупомянутых gst-плагинов.

А я специально написал "библиотеки" - решил небольшой тест провести. Тест дал положительные результаты ;)
В данном случае это не имеет значения - библиотеки или плагины. Если программе Opera эти файлы понадобились (а раньше в них необходимости не было - наши RPM-пакеты ставились в AltLinux без проблем) - значит зачем-то они нужны. И вся задача сводится к тому, чтобы этот самый доступ предоставить. На своей стороне вы менять ничего не хотите. Хорошо, тогда сообщите сборщикам Opera, что им нужно сделать, чтобы исправить положение. Докажите, почему вы правы, а все остальные дистрибутивы - нет.

Просто время идёт, а проблема не решена до сих пор. Страдают-то ведь не только наши, но и ваши пользователи.

Разница огромная - плагины это или библиотеки.

Для решения этой проблемы достаточно указать зависимости не на плагины, а на наши пакеты с этими плагинами.

Ну, и пакет собрать в среде ALT Linux'а, инструментами, принятыми у нас. Зависимости на библиотеки проставятся автоматически.

(In reply to comment #29)
> Разница огромная - плагины это или библиотеки.
> 
> Для решения этой проблемы достаточно указать зависимости не на плагины, а на
> наши пакеты с этими плагинами.

Т.е. в данном случае gst-plugins-base и gst-plugins-good?
А есть ли у нас способ указать зависимость на конкретные gst-плагины?
Или это действие не имеет смысла?

> Ну, и пакет собрать в среде ALT Linux'а, инструментами, принятыми у нас.
> Зависимости на библиотеки проставятся автоматически.

(В ответ на комментарий №29)
> Разница огромная - плагины это или библиотеки.

Ещё раз: в данном конкретном случае абсолютно не важно, что это - плагины, библиотеки или даже иконки 32х32. Решение лишь одно - связаться с разработчиками Opera и обсудить проблему. Или что, если бы это были библиотеки, то вы бы связались с нами сразу после возникновения проблемы, а раз это плагины - это ж совсем другое дело, тут можно забить и ждать у моря погоды? ;)

> Для решения этой проблемы достаточно указать зависимости не на плагины, а на
> наши пакеты с этими плагинами.

Это нужно не мне объяснять в вашем же внутреннем ресурсе, а используя предоставленные контакты обратиться напрямую к нашим девелоперам.

> 
> Ну, и пакет собрать в среде ALT Linux'а, инструментами, принятыми у нас.
> Зависимости на библиотеки проставятся автоматически.

Даже если и так (хотя вопрос спорный - наши текущие инструменты сборки прекрасно справляются с абсолютно всеми другими дистрибутивами), как наши сборщики должны об этом узнать? Выучить русский язык и перечитать документацию к Sisyphus? ;)
Или типа поискать обсуждение в конференции...

Повторю координаты:
Руар Одегард - Ruari Ødegaard <ruario@opera.com>
или можно отправить информацию непосредственно в BTS - DSK-305836@bugs.opera.com

Естественно, указать свои координаты для связи.

Парни, время идёт, а я который день пытаюсь уговорить кого-нибудь из команды Альтов хотя бы связаться с нами. Это не очень нормальная ситуация, мне кажется...

зависимость на конретные плагины имеет смысл, и у нас можно выбрать так:
$ rpm -q --provides gst-plugins-base
gstreamer(audio-hardware-sink) = 0.10.29
gstreamer(audio-hardware-source) = 0.10.29
gst-plugins-base-all = 0.10.29-alt2
gst-plugins-base-audio-filters = 0.10.29-alt2
gst-plugins-base-network = 0.10.29-alt2
gst-plugins-base-subtitle = 0.10.29-alt2
gst-plugins-base-test = 0.10.29-alt2
gst-plugins-base-video-filters = 0.10.29-alt2
gst-plugins-alsa = 0.10.29-alt2
gst-plugins-cdparanoia = 0.10.29-alt2
gst-plugins-ogg = 0.10.29-alt2
gst-plugins-theora = 0.10.29-alt2
gst-plugins-video4linux = 0.10.29-alt2
gst-plugins-vorbis = 0.10.29-alt2
gst-plugins-ximagesink = 0.10.29-alt2
gst-plugins-xvideo = 0.10.29-alt2
gst-plugins-base = 0.10.29-alt2

$ rpm -q --provides gst-plugins-good
gst-plugins-good-all = 0.10.23-alt1
gst-plugins-good-audio-filters = 0.10.23-alt1
gst-plugins-good-audio-formats = 0.10.23-alt1
gst-plugins-good-container-formats = 0.10.23-alt1
gst-plugins-good-network = 0.10.23-alt1
gst-plugins-good-tags = 0.10.23-alt1
gst-plugins-good-test = 0.10.23-alt1
gst-plugins-good-video-effects = 0.10.23-alt1
gst-plugins-good-video-filters = 0.10.23-alt1
gst-plugins-good-visualization = 0.10.23-alt1
gst-plugins-aalib = 0.10.23-alt1
gst-plugins-annodex = 0.10.23-alt1
gst-plugins-audiofx = 0.10.23-alt1
gst-plugins-cairo = 0.10.23-alt1
gst-plugins-cdio = 0.10.23-alt1
gst-plugins-dv = 0.10.23-alt1
gst-plugins-dv1394 = 0.10.23-alt1
gst-plugins-esd = 0.10.23-alt1
gst-plugins-flac = 0.10.23-alt1
gst-plugins-gdkpixbuf = 0.10.23-alt1
gst-plugins-hal = 0.10.23-alt1
gst-plugins-jpeg = 0.10.23-alt1
gst-plugins-png = 0.10.23-alt1
gst-plugins-shout2 = 0.10.23-alt1
gst-plugins-speex = 0.10.23-alt1
gst-plugins-taglib = 0.10.23-alt1
gst-plugins-video4linux2 = 0.10.23-alt1
gst-plugins-wavpack = 0.10.23-alt1
gst-plugins-ximagesrc = 0.10.23-alt1
gst-pulse = 0.10.23-alt1
gst-plugins-good = 0.10.23-alt1

(В ответ на комментарий №31)
> (В ответ на комментарий №29)
> > Разница огромная - плагины это или библиотеки.
> 
> Ещё раз: в данном конкретном случае абсолютно не важно, что это - плагины,
> библиотеки или даже иконки 32х32. Решение лишь одно - связаться с
> разработчиками Opera и обсудить проблему. Или что, если бы это были библиотеки,
> то вы бы связались с нами сразу после возникновения проблемы, а раз это плагины
> - это ж совсем другое дело, тут можно забить и ждать у моря погоды? ;)


Илья, вы, видимо, не понимаете суть ПРОБЛЕМЫ. Всё дело в том, что неприятности возникают не у наших пользователей, а у _ВАШИХ_ пользователей.

И я не понимаю, почему до сих пор ваши разработчики не связались с нашими, что бы мы помогли вам решить эту проблему.

> 
> > 
> > Ну, и пакет собрать в среде ALT Linux'а, инструментами, принятыми у нас.
> > Зависимости на библиотеки проставятся автоматически.
> 
> Даже если и так (хотя вопрос спорный - наши текущие инструменты сборки
> прекрасно справляются с абсолютно всеми другими дистрибутивами), как наши
> сборщики должны об этом узнать? Выучить русский язык и перечитать документацию
> к Sisyphus? ;)
> Или типа поискать обсуждение в конференции...

У нас есть англоязычные контакты... помимо списка рассылки - можно завести запись в bugzilla на английском, или связаться напрямую с руководством компании по адресу org at altlinux dot com

> 
> Повторю координаты:
> Руар Одегард - Ruari Ødegaard <ruario@opera.com>
> или можно отправить информацию непосредственно в BTS -
> DSK-305836@bugs.opera.com
> 
> Естественно, указать свои координаты для связи.
> 
> Парни, время идёт, а я который день пытаюсь уговорить кого-нибудь из команды
> Альтов хотя бы связаться с нами. Это не очень нормальная ситуация, мне
> кажется...

Не очень нормальная ситуация, когда вы уговариваете кого-то из Альтов, вместо того, что бы поставить задачу вашим разработчикам связаться с нашими, благо что контакты известны.

(В ответ на комментарий №33)
> (В ответ на комментарий №31)
> > (В ответ на комментарий №29)
> > > Разница огромная - плагины это или библиотеки.
> > 
> > Ещё раз: в данном конкретном случае абсолютно не важно, что это - плагины,
> > библиотеки или даже иконки 32х32. Решение лишь одно - связаться с
> > разработчиками Opera и обсудить проблему. Или что, если бы это были библиотеки,
> > то вы бы связались с нами сразу после возникновения проблемы, а раз это плагины
> > - это ж совсем другое дело, тут можно забить и ждать у моря погоды? ;)
> 
> 
> Илья, вы, видимо, не понимаете суть ПРОБЛЕМЫ. Всё дело в том, что неприятности
> возникают не у наших пользователей, а у _ВАШИХ_ пользователей.

Они такие же наши, как и ваши. Не находите? ;)

> 
> И я не понимаю, почему до сих пор ваши разработчики не связались с нашими, что
> бы мы помогли вам решить эту проблему.
> 
> > 
> > > 
> > > Ну, и пакет собрать в среде ALT Linux'а, инструментами, принятыми у нас.
> > > Зависимости на библиотеки проставятся автоматически.
> > 
> > Даже если и так (хотя вопрос спорный - наши текущие инструменты сборки
> > прекрасно справляются с абсолютно всеми другими дистрибутивами), как наши
> > сборщики должны об этом узнать? Выучить русский язык и перечитать документацию
> > к Sisyphus? ;)
> > Или типа поискать обсуждение в конференции...
> 
> У нас есть англоязычные контакты... помимо списка рассылки - можно завести
> запись в bugzilla на английском, или связаться напрямую с руководством компании
> по адресу org at altlinux dot com

Я это сделал ещё в четверг на прошлой неделе. И?

> 
> > 
> > Повторю координаты:
> > Руар Одегард - Ruari Ødegaard <ruario@opera.com>
> > или можно отправить информацию непосредственно в BTS -
> > DSK-305836@bugs.opera.com
> > 
> > Естественно, указать свои координаты для связи.
> > 
> > Парни, время идёт, а я который день пытаюсь уговорить кого-нибудь из команды
> > Альтов хотя бы связаться с нами. Это не очень нормальная ситуация, мне
> > кажется...
> 
> Не очень нормальная ситуация, когда вы уговариваете кого-то из Альтов, вместо
> того, что бы поставить задачу вашим разработчикам связаться с нашими, благо что
> контакты известны.

А я что делаю в данный момент? o_O
От имени разработчиков, не говорящих по-русски, связываюсь с вами и пытаюсь наладить прямой контакт между вами.

2ldv: Дима, на мой взгляд оптимальным вариантом для решения этой проблемы было бы провайдить плагины таким же образом, как они провайдятся у наших коллег из других дистрибутивов, ибо действительно, зависимость на конкретные плагины имеет смысл, а как их вытащить стандартным способом - не совсем понятно.

(In reply to comment #32)
> зависимость на конретные плагины имеет смысл, и у нас можно выбрать так:

OK, на что в данном случае было бы правильно заменить
$ rpmquery -pR opera-10.60-6386.x86_64.rpm |grep ^libgst
libgstautodetect.so()(64bit)  
libgstogg.so()(64bit)  
libgsttheora.so()(64bit)  
libgstvorbis.so()(64bit)  
libgstwavparse.so()(64bit)  
?

в случае с нашим gstreamer, полноценной замены этому я не вижу, о чём и сказал выше.

(In reply to comment #35)
> 2ldv: Дима, на мой взгляд оптимальным вариантом для решения этой проблемы было
> бы провайдить плагины таким же образом, как они провайдятся у наших коллег из
> других дистрибутивов,

Это противоречило бы нашим правилам:  плагин, размещённый в /usr/lib64/gstreamer-0.10/, нельзя провайдить под видом библиотеки, размещённой в /usr/lib64/.

Кроме того, пакет, будучи собранным в среде redhat, всё равно не получает те зависимости, которые должны были бы у него быть, если бы его собирали в среде altlinux.

> ибо действительно, зависимость на конкретные плагины
> имеет смысл, а как их вытащить стандартным способом - не совсем понятно.

Тут нужен совет специалиста по gst-plugins.

(In reply to comment #37)
> в случае с нашим gstreamer, полноценной замены этому я не вижу, о чём и сказал
> выше.

libgstogg.so -> gst-plugins-ogg
libgsttheora.so -> gst-plugins-theora
libgstvorbis.so -> gst-plugins-vorbis

Что касается отображения libgstautodetect.so и libgstwavparse.so, которые живут в gst-plugins-good, то тут мне не совсем понятно.  Вероятно, в пакете gst-plugins-good не хватает соответствующих provides.

2shrek: Валера, в чём причина такого различия:

$ rpmquery -lp gst-plugins-good-0.10.23-alt1.x86_64.rpm |grep wav
/usr/lib64/gstreamer-0.10/libgstwavenc.so
/usr/lib64/gstreamer-0.10/libgstwavpack.so
/usr/lib64/gstreamer-0.10/libgstwavparse.so
$ rpmquery --provides -p gst-plugins-good-0.10.23-alt1.x86_64.rpm |grep wav
gst-plugins-wavpack = 0.10.23-alt1

Каким образом wavpack оказался достойнее чем wavenc и wavparse?

$ comm -23 <(rpmquery -lp gst-plugins-good-0.10.23-alt1.x86_64.rpm |sed -n 's|^/usr/lib64/gstreamer-0.10/libgst\([^.]\+\)\.so.*|\1|p' |sort -u) <(rpmquery --provides -p gst-plugins-good-0.10.23-alt1.x86_64.rpm |sed -n 's/^gst-plugins-\([^- ]\+\) \+=.*/\1/p' |sort -u) | wc -l
48
т.е. ещё 48 плагинов остались без индивидуальных provides по какой-то особой причине?

> (In reply to comment #37)
> > в случае с нашим gstreamer, полноценной замены этому я не вижу, о чём и сказал
> > выше.
> 
> libgstogg.so -> gst-plugins-ogg
> libgsttheora.so -> gst-plugins-theora
> libgstvorbis.so -> gst-plugins-vorbis
> 
> Что касается отображения libgstautodetect.so и libgstwavparse.so, которые живут
> в gst-plugins-good, то тут мне не совсем понятно.  Вероятно, в пакете
> gst-plugins-good не хватает соответствующих provides.

И тут тоже есть одна проблема - в этой зависимости не хватает указания
архитектуры и в случае использования x86_32 это может привести к некорректному
поведению.

(In reply to comment #40)
> > (In reply to comment #37)
> > > в случае с нашим gstreamer, полноценной замены этому я не вижу, о чём и сказал
> > > выше.
> > 
> > libgstogg.so -> gst-plugins-ogg
> > libgsttheora.so -> gst-plugins-theora
> > libgstvorbis.so -> gst-plugins-vorbis
> > 
> > Что касается отображения libgstautodetect.so и libgstwavparse.so, которые живут
> > в gst-plugins-good, то тут мне не совсем понятно.  Вероятно, в пакете
> > gst-plugins-good не хватает соответствующих provides.
> 
> И тут тоже есть одна проблема - в этой зависимости не хватает указания
> архитектуры и в случае использования x86_32 это может привести к некорректному
> поведению.

Да, хотя архитектура gst-плагина и определяется архитектурой libgst*, с которыми слинковано приложение.

Если эта тема актуальна, то provides для gst-плагинов лучше было бы генерить автоматически в каком-нибудь разумном формате вроде gst-plugin(NAME)SUFFIX.

(In reply to comment #39)
> Каким образом wavpack оказался достойнее чем wavenc и wavparse?
Давным-давно все gst-plugins были распилены по разным пакетам, потом влились обратно в свои bad/good/ugly.  Эти provides появились для обратной совместимости.  Скорее всего wavenc и wavparse просто лежали вместе в пакете gst-plugins-wavpack.

Всем привет!

Есть какие-нибудь подвижки в этом вопросе?

(В ответ на комментарий №43)
> Есть какие-нибудь подвижки в этом вопросе?
А новая версия, пересобранная в среде ALT Linux, уже появилась на сайте Opera?

(В ответ на комментарий №44)
> А новая версия, пересобранная в среде ALT Linux, уже появилась на сайте Opera?

Если речь идет о моей перепакованной сборке - там непонятно как ее выкладывать на оффсайте, т.к. там 3 пакета, если упаковать под альт в один пакет - он потянет за собой gtk и qt4/kde4libs, что далеко не всем нужно.

(В ответ на комментарий №45)
> (В ответ на комментарий №44)
> > А новая версия, пересобранная в среде ALT Linux, уже появилась на сайте Opera?
> 
> Если речь идет о моей перепакованной сборке - там непонятно как ее выкладывать
> на оффсайте, т.к. там 3 пакета, если упаковать под альт в один пакет - он
> потянет за собой gtk и qt4/kde4libs, что далеко не всем нужно.

Парни, при чём тут сборка.
Я спрашивал - готов ли кто-нибудь из разработчиков AltLinux обсуждать эту проблему с нашими разработчиками?

(In reply to comment #44)
> (В ответ на комментарий №43)
> > Есть какие-нибудь подвижки в этом вопросе?
> А новая версия, пересобранная в среде ALT Linux, уже появилась на сайте Opera?

Боюсь что пока я им не напишу и не объясню, что к чему, этого не случится.  Oh well.

(В ответ на комментарий №47)
> (In reply to comment #44)
> > (В ответ на комментарий №43)
> > > Есть какие-нибудь подвижки в этом вопросе?
> > А новая версия, пересобранная в среде ALT Linux, уже появилась на сайте Opera?
> 
> Боюсь что пока я им не напишу и не объясню, что к чему, этого не случится.  Oh
> well.

Вообще-то я об этом уже неделю говорю. У нас в штате нет телепатов, которые могут читать мысли разработчиков AltLinux на расстоянии.

http://my.opera.com/russian/forums/topic.dml?id=593032&t=1279259549&page=3#comment6239502

============================================
Кстати, а Альты так и молчат... Мда.
Наши тестеры застопорили баг и ушли заниматься другими репортами. Ждём, когда хоть кто-нибудь из AltLinux хотя бы выйдет на связь и пояснит свою позицию.
============================================

Думаю, многим бы хотелось услышать что будет дальше. Либо сказать, что так собирать нельзя, либо сделать пакет-подпорку с нужными провайдами, либо?..

Собрал на скорую руку свой пакет: http://git.altlinux.org/people/baraka/packages/?p=opera-preinstall.git;a=summary

Но параллельно нашел еще один вариант более лучший, см. #23713

(В ответ на комментарий №50)
> Собрал на скорую руку свой пакет:
> http://git.altlinux.org/people/baraka/packages/?p=opera-preinstall.git;a=summary
> 
> Но параллельно нашел еще один вариант более лучший, см. #23713

Могло быть так:

Изменить процесс сборки одного пакета (сделать так, как делают другие дистрибутивы), который и так собирался майнтейнером AltLinux. Закрыть проблему раз и навсегда.

Стало так:

У одного из майнтейнеров появилась дополнительная задача - собирать ещё один пакет в среде AltLinux для каждой как минимум стабильной версии (хотя народ будет просить и беты, и даже тестовые сборки) как самой программы, так и собственного дистрибутива, осуществлять тестирование и исправление возможных косяков. Вместо того, чтобы потратить и так не резиновое время на более важные задачи.

IMHO, сомнительный профит...

(В ответ на комментарий №50)
> Собрал на скорую руку свой пакет:
> http://git.altlinux.org/people/baraka/packages/?p=opera-preinstall.git;a=summary
> 
> Но параллельно нашел еще один вариант более лучший, см. #23713

Зачем плодить велосипеды/костыли/подпорки/etc, есть можно сделать "правильно"?
http://git.altlinux.org/people/drool/packages/opera.git

Если что, я собрал пакет из репозитория Геннадия:
http://download.etersoft.ru/pub/Etersoft/LINUX@Etersoft/5.1/branch/i586/RPMS.addon/

Кто пользуется opera? исправлено?

Я пользуюсь. Сообщений таких больше нет, но из обсуждения не понятно была проблема решена или только спрятана от глаз пользователей.

А в чем, собственно, проблема? Перепаковка Opera в альтовой среде решает все поблемы с зависимостями. Сейчас ее перепаковываю и заливаю я, по зависимостям никаких замечаний нет. Собирать оперу под альт непосредственные разработчики не будут, это их официальная позиция. Но моей сборки, как-бы, хватает.

Значит официальная команда Альта поклала на это дело. :-)

Гена большое спасибо тебе за сборку!

Я не понял, на кого "поклала" команда Альта, если Opera собирается для Сизифа и бранчей. 
Закрываю.

(В ответ на комментарий №57)
> Значит официальная команда Альта поклала на это дело. :-)

А я, значит, неофициально в бранчи заливаю? :D