На дворе уже 1.0.2, в Сизифе по прежнему 0.9.8 двухлетней свежести. Мне эта библиотека понадобилась, посему я адаптировал спек для 1.0.2 (прикладывается). Также прикладываю патч, которые возвращает в пакет поддержку opendivx. В версии 0.9.10 эта поддержка была оторвана (возможно, из соображений варезности opendivx кода). Возможно, поддержку opendivx следует отключить по умолчанию, обернув всякими ifdef'ами. P.S. Могу взять пакет на себя.
Created attachment 2646 [details] spec для libquicktime-1.0.2
Created attachment 2647 [details] Тот самый патч для поддержки варезного opendivx
Спасибо! дописал вас в ACL на пакет. но пока не выкладывайте, пожалуйста. но есть еще одна тонкость, почему у меня никак руки не доходили, - апстрим не ведет soname. библиотека публичная, и сонейм 0.0.0 не годится. и либо прибить гвоздями сонейм вида .102.0.0 (хак) либо сделать symbol versioning, а также собрать compat библиотеку libquicktime098-compat с сонеймом 0.0.0 Если беретесь - то с чистой совестью полностью перевешиваю пакет на вас. Если нет, тогда надо будет немножко подождать, когда время выкрою. transcode-1.0.2-alt3.3M40.1 Depends: <libquicktime.so.0()(64bit)> libquicktime-0.9.8-alt6 libxawtv4-4.0-alt3.cvs20061123.1 Depends: <libquicktime.so.0()(64bit)> libquicktime-0.9.8-alt6 libmlt-0.2.2-alt0.7 Depends: <libquicktime.so.0()(64bit)> libquicktime-0.9.8-alt6 libmjpegtools-1.8.0-alt1 Depends: <libquicktime.so.0()(64bit)> libquicktime-0.9.8-alt6
Да, я видел этот баг... В принципе, работа для меня посильная (технически я представляю, как ввести версионирование soname), правда я так и до сих пор до конца не понял значение каждой из цифр версии soname. Если поможете разобраться (или укажите ссылочку, где это было бы разжёвано), тогда я готов взяться. А указанные Вами пакеты разве не вылечатся просто пересборкой с новой libquicktime?
вылечатся, конечно. compat не обязателен, не так много пакетов. было бы много, тогда пришлось бы...
правильно вести soname дожен апстрим, так как он знает, что где сломал. 102.0.0 - это ленивый метод. новой версии - новый soname - и такой, что не пересекается с возможным апстримным буде у них появится. он гарантирует, что клиенты не сломаются при обновлении библиотеки, но их придется пересобирать. более тонкая штука - symbol versioning. где посмотреть - например, начиная с http://freesource.info/wiki/AltLinux/Sisyphus/devel/soname?v=ttd&search=soname
и по нашему полиси ее лучше будет назвать libqucktime102 но libquicktime-devel http://freesource.info/wiki/AltLinux/Policy/Drafts/SharedLibs
С symbol versioning я разобрался. Может стоит попробовать повоевать с апстримом на предмет введения сабжа (начальный патч я готов предоставить). Что ж касается переименования пакета в libquicktime102, то мне эта мера кажется <пока> несколько преждевременной, т.к. пакет с таким названием в Сизифе всего один, если у него появится soname, то при увеличении его номера зависимые пакеты всё равно пересоберутся, а у непересобравшихся возникнет unmet. Конечно, переименование пакета несколько облегчает жизнь портировщикам, зато утяжеляет её мэйнтейнеру ;) Кстати, то, что написано по ссылке http://freesource.info/wiki/AltLinux/Policy/Drafts/SharedLibs -- это действующая policy или черновик?
(In reply to comment #8) > Конечно переименование пакета несколько облегчает жизнь портировщикам, Оно радикально упрощает жизнь бэкпортерам. > Кстати, то, что написано по ссылке > http://freesource.info/wiki/AltLinux/Policy/Drafts/SharedLibs -- это > действующая policy или черновик? Черновик. thresh так и не собрался пока с духом протолкнуть его в полиси.
Я пока думаю следующее: 1) Пока у библиотеки не появится нормальный soname, переименовывать рано. Т.к. во-первых, сильно затруднятся точечные обновления, а во-вторых, пока соответствующая policy не принята как действующая, заботиться об удалении старых версий из Сизифа придётся самостоятельно; 2) Упрощение жизни гипотетическим бэкпортерам приводит к усложнению жизни мэйнтейнера и любителей точечных обновлений. Оно того стоит, по крайней мере сейчас? Поэтому думаю, что вопрос переименования следует отложить до наступления одного из двух условий: либо принятию policy как обязательной, либо продавливания в upstream нормального версионирования (а вот об этом можно позаботиться уже сейчас). И ещё вопрос: если мы изменим soname на so.102.0.0, то не приведёт ли это к проблемам после того, как у библиотеки появится нормальный soname типа so.1.2.3?
1) это реальная грабля. например, a) собрать lqt без soname b) персобрать xdtv c новой lqt. c) кто-то переложит xdtv из Сизифа в branch 4.x. d) в branch 4.x xdtv падает :( если бы бы soname, то был бы unmet и не забыли бы переложить и правильный lqt. 2) никакой разницы нет что 102.0.0 -> 1.2.3 что 102.0.0 -> 103.0.0
Поэтому думаю, что вопрос переименования следует отложить до наступления одного из двух условий: либо принятию policy как обязательной полиси тут не причем, это just right way to do. Если что, я подсоблю. > либо продавливания в upstream нормального версионирования одно другому не мешает...
Мы немного друг друга не поняли. Я согласен с необходимостью введения soname (даже пусть пока вида 102.0.0), но считаю преждевременным переименование _пакета_ библиотеки в libquicktime102. Я считаю, что это стоит делать, когда у библиотеки появится нормальный soname (т.к. меняться он будет не слишком часто). Я готов сделать соответствующий патч и обсудить вопрос с апстримом на предмет его принятия и вычисления правильной версии.
без проблем. только хорошо бы проверить - Когда у библиотеки появится сонейм, все ли майнтайнеры зависимых пакетов смогут без проблем пересобрать свои пакеты - ведь переименование позволяет смягчить случай, когда некоторые пакеты не пересоберутся с новой библиотекой. Тогда и имеет смысл держать несколько версий одной библитоеки.
как вы там c libquicktime? я радостно вас нагрузил всем тем, чем сам должен был заняться. Боюcь, не перегрузил ли :(
Я сейчас доделываю один мой пакет, который хочет новую libquicktime. Когда доделаю (возможно, сегодня), то как раз планирую вернуться к libquicktime. Наверное, сегодня же попробую провентилировать вопрос с soname в апстриме. Так что если есть ещё пожелания -- милости прошу :)
Created attachment 2666 [details] Хак, вводящий версионирование soname Посмотрите, пожалуйста, на мой патч для поддержки версионирования soname в libquicktime. Если всё нормально, то я выложу пакет в incoming. В upstream я патч уже направил с пожеланием определить корректную версию.
на глаз патч хорош. Пора медали раздавать ;) Не будете возражать, если я вас выдвину в leader на пакет libquicktime?
Это всегда пожалуйста :) В общем, заливаю!
Пакет в Сизифе
