Bug 15814

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?

Это всегда пожалуйста :) В общем, заливаю!

Пакет в Сизифе