ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Shared Libs Policy check | ||
|---|---|---|---|
| Product: | Infrastructure | Reporter: | Zerg <anubix> |
| Component: | girar | Assignee: | placeholder <placeholder> |
| Status: | NEW --- | QA Contact: | Nobody's working on this, feel free to take it <nobody> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | aen, aris, at, boyarsh, cas, enp, evg, glebfm, icesik, ldv, legion, mithraen, real, shaba, shrek, viy, zerg |
| Version: | unspecified | ||
| Hardware: | all | ||
| OS: | Linux | ||
| URL: | http://www.altlinux.org/Shared_Libs_Policy_and_updates | ||
| Bug Depends on: | 29633, 32158, 34468, 39189, 51674, 51676, 28941, 29594, 30786, 31110, 32242, 35146, 37280 | ||
| Bug Blocks: | 29816 | ||
|
Description
Zerg
2013-05-08 21:16:45 MSK
Как ты себе представляешь проверку _изменения_ soname в sisyphus_check? Я представляю, что кто-то из подписчиков баги знает, на какой пакет перевесить при необходимости. Такая проверка сильно бы улучшила обновление с бранча на бранч. В качестве побочного эффекта при обновлении будут вылазить ситуации типа: "file /usr/share/libname/something из пакета libname5 конфликтует с одноименным файлом из libname10", но они легко исправляются и не портят систему. такую проверку можно сделать в repocop, добавить патчгенератор-переименовыватель, а отшивание пакетов заменить repocop NMU на эти пакеты. Думаю, раз есть интерес, то как только разберусь с java (там у меня eclipse подвис) попробую реализовать в repocop. (In reply to comment #4) > такую проверку можно сделать в repocop, > добавить патчгенератор-переименовыватель, > а отшивание пакетов заменить repocop NMU > на эти пакеты. Насколько я понимаю, важно именно не допустить неправильных обновлений в будущем, а не переименовывать то, что есть уже сейчас (за редкими исключениями, о которых мы уже давно знаем). Так что эта проверка должна работать иименно в сборочнице, а не снаружи. (В ответ на комментарий №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.
А он был бы ему идеальным майнтайнером :(
(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 нет клиентов. Я не вижу смысла налагать ограничения на библиотеки, у которых не более одного клиента. (В ответ на комментарий №7) > Я не вижу смысла налагать ограничения на библиотеки, > у которых не более одного клиента. Не более одного клиента из других src.rpm . Внутри одного src.rpm у меня в подпакетах зачастую дофига клиентов на одну библиотеку. (В ответ на комментарий №7) > Ну при чем тут sisyphus_check? http://lists.altlinux.org/pipermail/devel/2012-November/195849.html "Shared Libs Policy это действующие правила, для которых еще не написано проверок в sisyphus_check" ;-) (В ответ на комментарий №6) > > Так что эта проверка должна работать иименно в > > сборочнице, а не снаружи. > Почему? Потому что, когда уже выложено, исправить сложнее, т.к. добавляется необходимость исправления уже испорченного. (В ответ на комментарий №10) > Потому что, когда уже выложено, исправить сложнее Я не совсем понял, видимо. Лишь бы не попадало в репозитории до исправления. (В ответ на комментарий №4) > Думаю, раз есть интерес, то как только разберусь > с java (там у меня eclipse подвис) попробую > реализовать в repocop. Слыхать что-нибудь? (В ответ на комментарий №12) > (В ответ на комментарий №4) > > Думаю, раз есть интерес, то как только разберусь > > с java (там у меня eclipse подвис) попробую > > реализовать в repocop. > Слыхать что-нибудь? Прошу прощения, у меня еще руки до репокопа не дошли. (В ответ на комментарий №14) > (В ответ на комментарий №12) > > (В ответ на комментарий №4) > > > Думаю, раз есть интерес, то как только разберусь > > > с java (там у меня eclipse подвис) попробую > > > реализовать в repocop. > > Слыхать что-нибудь? > > Прошу прощения, у меня еще руки до репокопа не дошли. Хорошо бы они дошли скорее. Репокопа уже мало. Нужно на этапе сборки отсекать серпом по таким пакетам. Или более простой и менее хороший вариант: отшивать, если в репозитории среди провайдов уже имеется один из SONAME-ов, но в пакете с _другим_ именем. Еще вариант простой проверки: Если в пакете имеется библиотека с SONAME, то имя пакета должно оканчиваться на этот самый SONAME. Проверку проводить для каждой из библиотек, содержащихся в пакете. (В ответ на комментарий №18) > имя пакета должно оканчиваться на этот самый SONAME. Точнее, на версионное окончание этого SONAME. Для начала можно проверять не конец имени пакета а любое положение в имени. (В ответ на комментарий №20) > Для начала можно проверять не конец имени пакета а любое положение в имени. Тогда можно будет не менять пакеты типа libkf5kiocore . Из-за костыля http://git.altlinux.org/gears/a/apt.git?p=apt.git;a=commit;h=e2184306b28908f208869b791d1bb0550c659674 dist-upgrade периодически сносит кучи пакетов. (Ответ для Sergey V Turchin на комментарий #22) > Из-за костыля сносит Это оказалось ложным, погорячился. |
