34578 2018-02-22 15:50:05 +0300 rpmbuild: некорректная реализация %_deps_optimization: 2018-02-22 16:49:57 +0300 1 1 4 Development Sisyphus rpm-build unstable all Linux NEW P3 normal --- 1 viy placeholder arseny glebfm imz ldv placeholder vt qa-sisyphus oldest_to_newest 169208 0 viy 2018-02-22 15:50:05 +0300 пример: src rpm с 6000 подпакетов, http://autoextra.altlinux.org/pub/ALTLinux/rpmbuild-badmem/OUT.1/texlive-2016-alt0.24_39.20160520.src.rpm %_deps_optimization выключена, собирается за час, из них запись rpm 3 мин. Если для этого пакета в спеке включить %_deps_optimization, то %_deps_optimization выполняется более 3 суток (дольше терпения не хватило ждать). Как я понимаю, проблема связана с rpm API. Код %_deps_optimization имеет вид for i по подпакетам: for j по подпакетам: [...] изменитьRPMHeader(i) а внутри изменитьRPMHeader() происходит какое-то тяжелое действие, (позможно, пересжатие бинарного rpm)? поэтому код выполняется так долго, как 6000*6000 сохранений rpm = = 6000*(6000 сохранений=3мин) = 10 суток. исправленный код должен выглядеть, например, как-то так: for i по подпакетам: for j по подпакетам: [...] изменитьRPMHeader(i, только header в памяти) for i по подпакетам: сохранитьRPMHeader(i) Ясно, что в 4.0.4 это никто чинить не будет, однако в свете будущей миграции на rpm-build 4.13 вешаю баг с готовыми тяжелыми пакетами для тестрования. При переезде на 4.13 rpm API надо будет подправить и алгоритм для %_deps_optimization. 169210 1 ldv 2018-02-22 16:11:47 +0300 (In reply to comment #0) > пример: src rpm с 6000 подпакетов, > http://autoextra.altlinux.org/pub/ALTLinux/rpmbuild-badmem/OUT.1/texlive-2016-alt0.24_39.20160520.src.rpm > %_deps_optimization выключена, собирается за час, из них запись rpm 3 мин. > > Если для этого пакета в спеке включить %_deps_optimization, то > %_deps_optimization выполняется более 3 суток > (дольше терпения не хватило ждать). > > Как я понимаю, проблема связана с rpm API. > Код %_deps_optimization имеет вид > > for i по подпакетам: > for j по подпакетам: > [...] > изменитьRPMHeader(i) > > а внутри изменитьRPMHeader() происходит какое-то тяжелое действие, > (позможно, пересжатие бинарного rpm)? > поэтому код выполняется так долго, как 6000*6000 сохранений rpm = > = 6000*(6000 сохранений=3мин) = 10 суток. > > исправленный код должен выглядеть, например, как-то так: > > for i по подпакетам: > for j по подпакетам: > [...] > изменитьRPMHeader(i, только header в памяти) > > for i по подпакетам: > сохранитьRPMHeader(i) Сейчас алгоритм, грубо говоря, выглядит так: for i по подпакетам: for Di по зависимостям подпакета i: подумать(i, Di) for j по подпакетам: for Dj по зависимостям подпакета j: подумать(i, Di, i, Dj) изменитьRPMHeaderвПамяти(i) for i по подпакетам: сохранитьRPMHeader(i) 169212 2 viy 2018-02-22 16:20:53 +0300 гм. тогда я ошибся, поблема в чем-то другом. 169213 3 viy 2018-02-22 16:49:57 +0300 Тогда, если скрытых проблем нет, то это не баг, а фича - имплементация алгоритма с полиномиальной зависимостью времени исполнения от числа подпакетов. Для большинства пакетов работает, а для крайних случаев есть ручка, чтобы выключить. Если будет когда-нибудь стажер, можно дать ему задачу - написать для rpm 4.13 линейный по времени алгоритм. можно ставить в RESOLVED-WORKSFORME.