Так как пакет gst-plugins-base не провайдит своих библиотек они не видны ни ldconfig ни таким пакетам, как opera, требующим libgstvorbis.so и пачку других.
(В ответ на комментарий №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
