05.02.2018 02:35, Dmitry V. Levin пишет: > On Sun, Feb 04, 2018 at 02:55:30AM +0300, Ivan Zakharyaschev wrote: >> On Sun, 4 Feb 2018, Dmitry V. Levin wrote: >>> On Sat, Feb 03, 2018 at 07:41:04AM +0300, Anton Farygin wrote: >>>> 03.02.2018 03:14, Dmitry V. Levin пишет: >>>>> On Fri, Feb 02, 2018 at 07:44:20AM +0300, Anton Farygin wrote: >>>>>> 02.02.2018 04:39, Alexei Takaseev пишет: >>>>>>> Добрый день! >>>>>>> >>>>>>> ----- Исходное сообщение ----- >>>>>>>> От: "ALT beekeeper" >>>>>>>> Кому:sisyphus-cybertalk@lists.altlinux.org >>>>>>>> Отправлено: Пятница, 2 Февраль 2018 г 0:42:58 >>>>>>>> Тема: [cyber] I: Sisyphus-20180201 i586 beehive_status: +1151 -6 (1510) >>>>>>> В Сизифе что-то большое рвануло? >>>>>> Когда-то давным давно в пакеты python пробралась паразитная сборочная >>>>>> зависимость на пакет python-module-setuptools-tests (кто-то в офисе в >>>>>> Москве предположил, что это могло произойти через некорректное >>>>>> использование buildreq) >>>>>> >>>>>> Сейчас этого пакета нет, но зависимость осталась. Чинится пересборкой с >>>>>> заменой сборочной зависимости на python-module-setuptools. И я >>>>>> предполагаю, что это исправят в ближайшее время скриптом (тот же кто и >>>>>> сломал). >>>>> Может, проще было бы добавить provides для обратной совместимости, >>>>> чем пересобирать сотни пакетов? >>>> Может быть и проще, но правильнее и честнее пересобрать. >>> Почему правильнее? Станут ли Пакеты, полученные в результате пересборки, >>> лучше прежних? >> По идее (без рассмотрения конкретно этого случая), пакеты python*-tests >> никому не должны быть нужны ни в runtime, ни при сборке (за исключением, >> возможно, каких-то хитрых %check). (Просто тесты, которые можно запустить >> в системе.) > По идее да. > >>> Правильнее пересобирать все компилируемые пакеты после обновления >>> тулчейна, мы готовы к этому? >> Убрать такую сборочную зависимость -- более существенное улучшение в >> структуре репозитория Sisyphus, чем просто пересборка отдельных пакетов. > Убрать конкретно эту, или все python*-tests? > >> По идее, их можно было бы сложить в отдельную компоненту все и не >> нагружать обычные pkglists, если уж сложилась практика их паковать. Но >> плодить компоненты, про которые никто не будет знать, тоже не хочется. >> Можно было бы одну компоненту junk завести. >> >> Помимо предположения о том, что какие-то хитрые %check могут использовать >> чужие python*-tests, можно сказать, что пакеты *-checkinstall должны иметь >> возможность использоввать python*-tests (не в виде исключения, а как >> обычное дело). >> >> (Отличие python*-tetss от *-checkinstall в том, что первые просто >> содержат тексты тестов, а вторые их запускают при установке пакета.) >> >> По теме: Provides: python*-tests в нормальном пакете был бы некрасивым >> костылём (каким-то обманом, потому что вообще-то такая сущность не должна >> исользоваться в BuildRequires). > Это всё хорошо, конечно, но какое это имеет отношение к данному > конкретному случаю? Я не вижу, чтобы в результате автоматизированной > слепой пересборки с удалением атавистической сборочной зависимости > полученные пакеты были бы лучше прежних. Нагрузку на сборочницу вижу, > трафик вижу, а в чём польза-то? В данном случае пересборка python пакетов с удалением/заменой сборочной зависимости является вынужденной мерой ( исправление ошибки включения такой зависимости когда-то в прошлом). И лучше от этого они ( сами пакеты) действительно не становятся. Было бы здорово, если бы существовал механизм отложенного применения действия - изменение спека происходит в настоящем (виртуальный спек?), который, например, отображается на репозитории/ях, а фактическое применение - во время следующей сборки. Спасибо.