Bug 34578 - rpmbuild: некорректная реализация %_deps_optimization:
Summary: rpmbuild: некорректная реализация %_deps_optimization:
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: rpm-build (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: placeholder@altlinux.org
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-22 15:50 MSK by viy
Modified: 2018-02-22 16:49 MSK (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description viy 2018-02-22 15:50:05 MSK
пример: 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.
Comment 1 Dmitry V. Levin 2018-02-22 16:11:47 MSK
(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)
Comment 2 viy 2018-02-22 16:20:53 MSK
гм. тогда я ошибся, поблема в чем-то другом.
Comment 3 viy 2018-02-22 16:49:57 MSK
Тогда, если скрытых проблем нет, то это не баг, а фича - имплементация алгоритма с полиномиальной зависимостью времени исполнения от числа подпакетов.

Для большинства пакетов работает, а для крайних случаев есть  ручка, чтобы выключить.

Если будет когда-нибудь стажер, можно дать ему задачу - написать
для rpm 4.13 линейный по времени алгоритм.

можно ставить в RESOLVED-WORKSFORME.