[devel] Сборочница: никогда такого не было, и вот опять.

[Igor Vlasenko]

Сборочница: никогда такого не было, и вот опять.

Уважаемые коллеги!

Хотел бы еще раз привлечь внимание к багу сборочницы
 https://bugzilla.altlinux.org/39276 --
для сборки пакетов используются одни и те же значения лимитов
hasher-priv без возможности как-то на них повлиять.

Это до боли напоминает "прокрустово ложе", историю о борце за
человеческое равенство разбойнике Прокрусте,
Добрый разбойник всех, кто к нему попадал, укладывал на свое ложе;
тем, для кого ложе было коротко, он отрубал ноги,
а у тех, для кого оно было слишком длинно, он ноги вытягивал.

Логика подсказывает, что лимиты должны быть не абсолютными, а
соразмерными пакету. Было бы странно дом для скворца - скворечник,
будку для собаки и сарай для слона делать одинаковыми физически.
Однако сборочница именно так и устроена.

К примеру, лимит wlimit_time_idle.
Прямо сейчас в репозитории 6 пакетов
java-1.8.0-openjdk
java-9-openjdk
java-10-openjdk
java3d
jogl2
qt5-webengine

обманывают сборочницу и обходят этот лимит с помощью вставки в спек
кода вида (while true; do date; sleep 7m; done) &

Чем плох такой обман?
1) замусоривается лог сборки
2) вместо предохранителя wlimit_time_idle мы устанавливаем "жучёк".
Если вдруг, к примеру, выбьет тесты, и сборка зависнет, то
wlimit_time_idle не сработает, так как будет продолжать идти мусор от
фонового sleep;date.

Следующий лимит, wlimit_time_elapsed, уже обойти нельзя.
Уважаемый Дмитрий не хочет ничего делать в этом случае,
отговаривается тем, что таких пакетов в нормальных случаях быть не может.

Здесь я навскидку приведу 4 примера, где как раз сам пакет честный,
а сборка упирается в wlimit_time_elapsed.

* библиотека libint, с которой и начался #39276
* монолитный texlive-2016
* java-9-openjdk и его эпическая история бутстрап сборки в p9 на armh,
  см. https://bugzilla.altlinux.org/39614
* свежий пример, о котором я рассказывал в Переяславле,
  #274515 FAILED #2 sisyphus srpm=scala-2.10.6-alt3_17jpp8.src.rpm (armh).

С добавлением новых архитектур сложилась ситуация, когда
вполне возможно, что в Сизифе таких пакетов, как старая scala (java8+armh)
несколько десятков, они как мины, ждут, когда их наконец
попробуют пересобрать на armh, чтобы взорваться на
wlimit_time_elapsed. Поэтому я и интенсивно переезжаю на java11,
а java8only пакеты сразу массово выбрасываю в топку, чтобы не
связываться со сборочницей.

Как я уже говорил, это очень неприятная проблема на ровном месте.

И вот теперь прозвенел первый звоночек уже и в отношении
лимита wlimit_bytes_written. Он должен защищать нас
от бесконечного цикла, забивающего лог мусором.

Впервые на моей памяти честный лог сборки в задании
#282652 FAILED #2 sisyphus srpm=openjfx-11.0.9.2-alt1_6jpp11.src.rpm
вылез за wlimit_bytes_written.

Конечно wlimit_bytes_written, как и wlimit_time_idle, можно обойти.
Можно отключить наиболее частые warnings. Можно выставить VERBOSE=0.
Доводя до логического конца, можно вообще написать в спеке
абсурд, зеркально подчеркивающий абсурд фиксированных лимитов,
написать

make build >/dev/null 2>&1

Э8()

Но openjfx только первая ласточка. Это не отменит того факта,
что исходники растут, и вполне может быть, что уже через год
пакеты, не вписывающиеся в wlimit_bytes_written,
тоже будут исчисляться десятками.

Как мне хочется спокойно собирать пакеты, а приходится
бороться со сборочницей, занимаясь глупостями
вроде обходов лимитов.

Надо подумать наперед и чинить это сейчас, а не ждать,
когда эта проблема начнет вырастать
из пока еще проблемы 2-3 человек (viy,zerg,...)
в проблему по настоящему массовую.


-- 

I V