Bug 28944 - Shared Libs Policy check
Summary: Shared Libs Policy check
Status: NEW
Alias: None
Product: Infrastructure
Classification: Infrastructure
Component: girar (show other bugs)
Version: unspecified
Hardware: all Linux
: P3 enhancement
Assignee: placeholder@altlinux.org
QA Contact: Nobody's working on this, feel free to take it
URL: http://www.altlinux.org/Shared_Libs_P...
Keywords:
Depends on: 29633 32158 34468 39189 28941 29594 30786 31110 32242 35146 37280
Blocks: 29816
  Show dependency tree
 
Reported: 2013-05-08 21:16 MSK by Zerg
Modified: 2023-11-13 10:07 MSK (History)
17 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zerg 2013-05-08 21:16:45 MSK
Предлагаю добавить минимальную проверку на упаковку библиотек.
Отшивать пакеты, если изменился soname, а имя пакета не изменилось.
Например, сейчас проблемы с обновлением p6 на p7. bug#28941
Comment 1 Dmitry V. Levin 2013-05-08 21:33:24 MSK
Как ты себе представляешь проверку _изменения_ soname в sisyphus_check?
Comment 2 Zerg 2013-05-08 21:58:43 MSK
Я представляю, что кто-то из подписчиков баги знает, на какой пакет перевесить при необходимости.
Comment 3 Zerg 2013-05-09 14:00:34 MSK
Такая проверка сильно бы улучшила обновление с бранча на бранч.

В качестве побочного эффекта при обновлении будут вылазить ситуации типа:
"file /usr/share/libname/something из пакета libname5 конфликтует с одноименным файлом из libname10", но они легко исправляются и не портят систему.
Comment 4 viy 2013-05-11 01:28:22 MSK
такую проверку можно сделать в repocop,
добавить патчгенератор-переименовыватель,
а отшивание пакетов заменить repocop NMU 
на эти пакеты.

Думаю, раз есть интерес, то как только разберусь 
с java (там у меня eclipse подвис) попробую 
реализовать в repocop.
Comment 5 Dmitry V. Levin 2013-05-11 01:34:04 MSK
(In reply to comment #4)
> такую проверку можно сделать в repocop,
> добавить патчгенератор-переименовыватель,
> а отшивание пакетов заменить repocop NMU 
> на эти пакеты.

Насколько я понимаю, важно именно не допустить неправильных обновлений в будущем, а не переименовывать то, что есть уже сейчас (за редкими исключениями, о которых мы уже давно знаем).  Так что эта проверка должна работать иименно в сборочнице, а не снаружи.
Comment 6 viy 2013-05-11 02:14:26 MSK
(В ответ на комментарий №5)
> Насколько я понимаю, важно именно не допустить неправильных обновлений в
> будущем, а не переименовывать то, что есть уже сейчас (за редкими исключениями,
> о которых мы уже давно знаем).  Так что эта проверка должна работать иименно в
> сборочнице, а не снаружи.

Почему?
Допустим, X выложил icu с подпакетом libicu c so.5 c с другим сонеймом.
repocop:
патч репокопа переименует подпакет libicu в libicu5.
на момент обновления p7->p8 в Сизифе все будет ок, 
обычные пользователи насладятся благами безглючного обновления,
но те (несколько десятков?) пользователей, которые "сидят на сизифе"
могут испытать неудобства при обновлении, но там все сплошь бойцы.
sisyphus_check:
остановит libicu, но в силу design flow (проверки-то не отключаемые)
создаст большие проблемы майнтайнерам во всяких крайних случаях вроде random soname.
Неудачный зажим гаек в sisyphus_check нагружает майнтайнеров дурной работой
и создает недовольство в коллективе, что политически не правильно.
Например, я стал майнтайнером из-за того, как из-за подобного недовольства из team с матами ушел Alex Ott, и бросил Emacs.
А он был бы ему идеальным майнтайнером :(
Comment 7 Dmitry V. Levin 2013-05-11 03:34:28 MSK
(In reply to comment #6)
> (В ответ на комментарий №5)
> > Насколько я понимаю, важно именно не допустить неправильных обновлений в
> > будущем, а не переименовывать то, что есть уже сейчас (за редкими исключениями,
> > о которых мы уже давно знаем).  Так что эта проверка должна работать иименно в
> > сборочнице, а не снаружи.
> 
> Почему?
> Допустим, X выложил icu с подпакетом libicu c so.5 c с другим сонеймом.
> repocop:
> патч репокопа переименует подпакет libicu в libicu5.
> на момент обновления p7->p8 в Сизифе все будет ок, 
> обычные пользователи насладятся благами безглючного обновления,
> но те (несколько десятков?) пользователей, которые "сидят на сизифе"
> могут испытать неудобства при обновлении, но там все сплошь бойцы.

Ну да, и остальные проверки на репозиторий тоже перенести в repocop.
Например, зачем нам проверка на анметы, ведь мйнтейнерам так тяжело, поэтому на момент обновления p7->p8 все будет хорошо, а на сизифе с анметами просто никого не останется.  Нет, спасибо, это пройденный этап.

> sisyphus_check:

Ну при чем тут sisyphus_check?  Это такая же примерно проверка, как и проверка на анметы.

> остановит libicu, но в силу design flow (проверки-то не отключаемые)

Проверки в сборочнице настраиваемые.

> создаст большие проблемы майнтайнерам во всяких крайних случаях вроде random
> soname.

У библиотек со случайным soname нет клиентов.  Я не вижу смысла налагать ограничения на библиотеки, у которых не более одного клиента.
Comment 8 Sergey V Turchin 2013-05-13 16:25:50 MSK
(В ответ на комментарий №7)
> Я не вижу смысла налагать ограничения на библиотеки,
> у которых не более одного клиента.
Не более одного клиента из других src.rpm .
Внутри одного src.rpm у меня в подпакетах зачастую дофига клиентов на одну библиотеку.
Comment 9 Sergey V Turchin 2013-05-13 16:27:07 MSK
(В ответ на комментарий №7)
> Ну при чем тут sisyphus_check?
http://lists.altlinux.org/pipermail/devel/2012-November/195849.html
"Shared Libs Policy это действующие правила, для которых еще не написано проверок в sisyphus_check" ;-)
Comment 10 Sergey V Turchin 2013-05-13 16:32:42 MSK
(В ответ на комментарий №6)
> > Так что эта проверка должна работать иименно в
> > сборочнице, а не снаружи.
> Почему?
Потому что, когда уже выложено, исправить сложнее, т.к. добавляется необходимость исправления уже испорченного.
Comment 11 Sergey V Turchin 2013-05-13 16:33:55 MSK
(В ответ на комментарий №10)
> Потому что, когда уже выложено, исправить сложнее
Я не совсем понял, видимо. Лишь бы не попадало в репозитории до исправления.
Comment 12 Sergey V Turchin 2013-12-13 14:45:36 MSK
(В ответ на комментарий №4)
> Думаю, раз есть интерес, то как только разберусь 
> с java (там у меня eclipse подвис) попробую 
> реализовать в repocop.
Слыхать что-нибудь?
Comment 13 Sergey V Turchin 2013-12-13 17:03:28 MSK
Профит http://www.altlinux.org/Shared_Libs_Policy_and_updates
Comment 14 viy 2013-12-14 03:38:37 MSK
(В ответ на комментарий №12)
> (В ответ на комментарий №4)
> > Думаю, раз есть интерес, то как только разберусь 
> > с java (там у меня eclipse подвис) попробую 
> > реализовать в repocop.
> Слыхать что-нибудь?

Прошу прощения, у меня еще руки до репокопа не дошли.
Comment 15 AEN 2014-02-10 22:41:25 MSK
(В ответ на комментарий №14)
> (В ответ на комментарий №12)
> > (В ответ на комментарий №4)
> > > Думаю, раз есть интерес, то как только разберусь 
> > > с java (там у меня eclipse подвис) попробую 
> > > реализовать в repocop.
> > Слыхать что-нибудь?
> 
> Прошу прощения, у меня еще руки до репокопа не дошли.

Хорошо бы они дошли скорее.
Comment 16 Zerg 2014-02-10 23:25:54 MSK
Репокопа уже мало. Нужно на этапе сборки отсекать серпом по таким пакетам.
Comment 17 Zerg 2014-02-11 04:49:39 MSK
Или более простой и менее хороший вариант: отшивать, если в репозитории среди провайдов уже имеется один из SONAME-ов, но в пакете с _другим_ именем.
Comment 18 Sergey V Turchin 2015-02-19 19:31:49 MSK
Еще вариант простой проверки:
Если в пакете имеется библиотека с SONAME, то имя пакета должно оканчиваться на этот самый SONAME.

Проверку проводить для каждой из библиотек, содержащихся в пакете.
Comment 19 Sergey V Turchin 2015-02-19 19:33:24 MSK
(В ответ на комментарий №18)
> имя пакета должно оканчиваться на этот самый SONAME.
Точнее, на версионное окончание этого SONAME.
Comment 20 Sergey V Turchin 2015-04-16 16:49:57 MSK
Для начала можно проверять не конец имени пакета а любое положение в имени.
Comment 21 Sergey V Turchin 2016-01-14 15:49:40 MSK
(В ответ на комментарий №20)
> Для начала можно проверять не конец имени пакета а любое положение в имени.
Тогда можно будет не менять пакеты типа libkf5kiocore .
Comment 22 Sergey V Turchin 2018-08-09 17:34:07 MSK
Из-за костыля http://git.altlinux.org/gears/a/apt.git?p=apt.git;a=commit;h=e2184306b28908f208869b791d1bb0550c659674 dist-upgrade периодически сносит кучи пакетов.
Comment 23 Sergey V Turchin 2020-04-15 19:51:11 MSK
(Ответ для Sergey V Turchin на комментарий #22)
> Из-за костыля сносит
Это оказалось ложным, погорячился.