28944 2013-05-08 21:16:45 +0400 Shared Libs Policy check 2026-01-25 18:02:09 +0300 1 1 2 Infrastructure Infrastructure girar unspecified all Linux NEW http://www.altlinux.org/Shared_Libs_Policy_and_updates P3 enhancement --- 29633 32158 34468 39189 51674 51676 57641 28941 29594 30786 31110 32242 35146 37280 57054 29816 1 anubix placeholder aen aris at boyarsh cas enp evg glebfm icesik ldv legion mithraen real shaba shrek viy zerg nobody oldest_to_newest 140160 0 anubix 2013-05-08 21:16:45 +0400 Предлагаю добавить минимальную проверку на упаковку библиотек. Отшивать пакеты, если изменился soname, а имя пакета не изменилось. Например, сейчас проблемы с обновлением p6 на p7. bug#28941 140164 1 ldv 2013-05-08 21:33:24 +0400 Как ты себе представляешь проверку _изменения_ soname в sisyphus_check? 140166 2 anubix 2013-05-08 21:58:43 +0400 Я представляю, что кто-то из подписчиков баги знает, на какой пакет перевесить при необходимости. 140175 3 anubix 2013-05-09 14:00:34 +0400 Такая проверка сильно бы улучшила обновление с бранча на бранч. В качестве побочного эффекта при обновлении будут вылазить ситуации типа: "file /usr/share/libname/something из пакета libname5 конфликтует с одноименным файлом из libname10", но они легко исправляются и не портят систему. 140219 4 viy 2013-05-11 01:28:22 +0400 такую проверку можно сделать в repocop, добавить патчгенератор-переименовыватель, а отшивание пакетов заменить repocop NMU на эти пакеты. Думаю, раз есть интерес, то как только разберусь с java (там у меня eclipse подвис) попробую реализовать в repocop. 140220 5 ldv 2013-05-11 01:34:04 +0400 (In reply to comment #4) > такую проверку можно сделать в repocop, > добавить патчгенератор-переименовыватель, > а отшивание пакетов заменить repocop NMU > на эти пакеты. Насколько я понимаю, важно именно не допустить неправильных обновлений в будущем, а не переименовывать то, что есть уже сейчас (за редкими исключениями, о которых мы уже давно знаем). Так что эта проверка должна работать иименно в сборочнице, а не снаружи. 140222 6 viy 2013-05-11 02:14:26 +0400 (В ответ на комментарий №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. А он был бы ему идеальным майнтайнером :( 140223 7 ldv 2013-05-11 03:34:28 +0400 (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 нет клиентов. Я не вижу смысла налагать ограничения на библиотеки, у которых не более одного клиента. 140276 8 zerg 2013-05-13 16:25:50 +0400 (В ответ на комментарий №7) > Я не вижу смысла налагать ограничения на библиотеки, > у которых не более одного клиента. Не более одного клиента из других src.rpm . Внутри одного src.rpm у меня в подпакетах зачастую дофига клиентов на одну библиотеку. 140277 9 zerg 2013-05-13 16:27:07 +0400 (В ответ на комментарий №7) > Ну при чем тут sisyphus_check? http://lists.altlinux.org/pipermail/devel/2012-November/195849.html "Shared Libs Policy это действующие правила, для которых еще не написано проверок в sisyphus_check" ;-) 140278 10 zerg 2013-05-13 16:32:42 +0400 (В ответ на комментарий №6) > > Так что эта проверка должна работать иименно в > > сборочнице, а не снаружи. > Почему? Потому что, когда уже выложено, исправить сложнее, т.к. добавляется необходимость исправления уже испорченного. 140279 11 zerg 2013-05-13 16:33:55 +0400 (В ответ на комментарий №10) > Потому что, когда уже выложено, исправить сложнее Я не совсем понял, видимо. Лишь бы не попадало в репозитории до исправления. 144239 12 zerg 2013-12-13 14:45:36 +0400 (В ответ на комментарий №4) > Думаю, раз есть интерес, то как только разберусь > с java (там у меня eclipse подвис) попробую > реализовать в repocop. Слыхать что-нибудь? 144255 13 zerg 2013-12-13 17:03:28 +0400 Профит http://www.altlinux.org/Shared_Libs_Policy_and_updates 144275 14 viy 2013-12-14 03:38:37 +0400 (В ответ на комментарий №12) > (В ответ на комментарий №4) > > Думаю, раз есть интерес, то как только разберусь > > с java (там у меня eclipse подвис) попробую > > реализовать в repocop. > Слыхать что-нибудь? Прошу прощения, у меня еще руки до репокопа не дошли. 145183 15 aen 2014-02-10 22:41:25 +0400 (В ответ на комментарий №14) > (В ответ на комментарий №12) > > (В ответ на комментарий №4) > > > Думаю, раз есть интерес, то как только разберусь > > > с java (там у меня eclipse подвис) попробую > > > реализовать в repocop. > > Слыхать что-нибудь? > > Прошу прощения, у меня еще руки до репокопа не дошли. Хорошо бы они дошли скорее. 145185 16 anubix 2014-02-10 23:25:54 +0400 Репокопа уже мало. Нужно на этапе сборки отсекать серпом по таким пакетам. 145190 17 anubix 2014-02-11 04:49:39 +0400 Или более простой и менее хороший вариант: отшивать, если в репозитории среди провайдов уже имеется один из SONAME-ов, но в пакете с _другим_ именем. 150388 18 zerg 2015-02-19 19:31:49 +0300 Еще вариант простой проверки: Если в пакете имеется библиотека с SONAME, то имя пакета должно оканчиваться на этот самый SONAME. Проверку проводить для каждой из библиотек, содержащихся в пакете. 150389 19 zerg 2015-02-19 19:33:24 +0300 (В ответ на комментарий №18) > имя пакета должно оканчиваться на этот самый SONAME. Точнее, на версионное окончание этого SONAME. 151196 20 zerg 2015-04-16 16:49:57 +0300 Для начала можно проверять не конец имени пакета а любое положение в имени. 154568 21 zerg 2016-01-14 15:49:40 +0300 (В ответ на комментарий №20) > Для начала можно проверять не конец имени пакета а любое положение в имени. Тогда можно будет не менять пакеты типа libkf5kiocore . 173341 22 zerg 2018-08-09 17:34:07 +0300 Из-за костыля http://git.altlinux.org/gears/a/apt.git?p=apt.git;a=commit;h=e2184306b28908f208869b791d1bb0550c659674 dist-upgrade периодически сносит кучи пакетов. 189272 23 zerg 2020-04-15 19:51:11 +0300 (Ответ для Sergey V Turchin на комментарий #22) > Из-за костыля сносит Это оказалось ложным, погорячился.