Bug 12928

PS: если собрать 0.6.0-alt10 в среде 4.0/branch, данная зависимость не
появляется.  Если такую сборку поставить и захолдить, то при попытке
dist-upgrade будет предложение поставить installer-stage2 и всё ненужное на
обычной системе, что он за собой тащит.

Получается, в сизифе сейчас сломаны и rpm-build, и apt? (подробности дописываю в
sisyphus@)

Ага.

On Thu, Sep 27, 2007 at 02:59:44PM +0400, Alexey Tourbin wrote:
> On Thu, Sep 27, 2007 at 02:36:20PM +0400, Stanislav Ievlev wrote:  
> > А то вот spt стал зависит от installer-stage2,
> 
> shell.req: /usr/src/tmp/spt-buildroot/usr/bin/spt: postinstall ->
/usr/sbin/postinstall -> installer-stage2 (via contents_index_bin)

Там есть одноимённая функция postinstall.

Если у пакета spt есть зависимость на installer-stage2, то это проблема пакетов
spt и installer-stage2.

Если у вас есть конструктивные предложения по пакету rpm-build, будьте добры
оформлять их отдельно.

(In reply to comment #3)
> Если у пакета spt есть зависимость на installer-stage2, то это проблема пакетов
> spt и installer-stage2.
Эта зависимость не фиксирована в spt.spec и появляется там вследствие
ошибки/недоработки текущего rpm-build.  Когда полезут другие не менее
феерические букеты -- тоже виноваты будут крайние или всё-таки root cause?

> Если у вас есть конструктивные предложения по пакету rpm-build, будьте добры
> оформлять их отдельно.
Не цепляться за шелловые функции, если не сказано явно (например, AutoReq: yes,
shellfunc).  Предложение переписать весь шелловый мир на заведомо уникальные и
не пересекающиеся ни с чем в $PATH имена функций мной лично будет встречено
переходом на 4.0/branch в краткосрочной перспективе и на более вменяемый
репозиторий -- в среднесрочной.

Дима, от тебя -- не ожидал.

Мы будем улучшать генератор shell-зависимоcтей, который сейчас работает в
практически неизменном виде с апреля 2003 года, вне зависимости от того, какие
зависимости будут у пакета spt.

Зависимости пакета spt нужно исправить, не дожидаясь улучшенного генератора
shell-зависимоcтей.

Миша, тебе придётся согласится с тем, что моё решение по этому вопросу является
окончательным.

> Миша, тебе придётся согласится с тем, что моё решение по этому вопросу является
> окончательным.
Дима, мне придётся обратить внимание на salvation clause в своём сообщении о
статусе поддерживаемых пакетов, если приоритет отношения к людям в этом проекте
сменился приоритетом отношения к байтикам.

Сказка на ночь:

     -- Мне хотелось бы полюбоваться закатом... Окажите мне милость,  велите
солнцу зайти...
     --  Если  бы я  приказал генералу порхать  с  цветка на  цветок подобно
бабочке, или написать трагическую пьесу,  или превратиться в птицу,  парящую
над морем, а генерал не исполнил  полученный приказ, кто из нас двоих был бы
повинен в этом? -- сердито спросил король. -- Генерал или я сам?
     -- Вы, -- твердо ответил принц.

http://www.lib.ru/EKZUPERY/mprinc_s.txt

А теперь от лирики к делу.

Есть проблема -- нынешний генератор зависимостей ставит ложные зависимости.
Новый генератор зависимостей позволил локализовать и решить целый ряд проблем,
однако породил как минимум одну известную новую -- простановка ложных
зависимостей, при использовании функций с именами, которые совпадают с именами
каких-либо файлов в $PATH.

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

Как можно решить эту проблему?

Боюсь сейчас надо повесить багу на rpm-build, а эту багу сделать зависимой от
той, либо решить эту конкретную багу местечковым хаком с переименованием функции.

(In reply to comment #7)
> А теперь от лирики к делу.
> 
> Есть проблема -- нынешний генератор зависимостей ставит ложные зависимости.
> Новый генератор зависимостей позволил локализовать и решить целый ряд проблем,
> однако породил как минимум одну известную новую -- простановка ложных
> зависимостей, при использовании функций с именами, которые совпадают с именами
> каких-либо файлов в $PATH.

Кажется вы все о чём-то другом говорите.
Ложную зависимость в пакете spt поставил старый добрый генератор зависимостей.
Новый генератор ещё находится в тестировании.

> Как можно решить эту проблему?
> 
> Боюсь сейчас надо повесить багу на rpm-build, а эту багу сделать зависимой от
> той, либо решить эту конкретную багу местечковым хаком с переименованием функции.

С выводом согласен, хотя предпосылка была в корне неверная.

Спасибо за уточнение, повесил багу на rpm-build.

А теперь возвращаясь с небес на землю -- думаю что конкретно эту багу стоит
пофиксить грязным хаком немедленно, не дожидаясь исправления в rpm-build.

(In reply to comment #9)
> А теперь возвращаясь с небес на землю -- думаю что конкретно эту багу стоит
> пофиксить грязным хаком немедленно, не дожидаясь исправления в rpm-build.
О чём Дима и говорил.

А теперь слишком мало зависимостей:

$ compare_packages -a -R -- spt-0.6.0-alt7.noarch.rpm --
spt-0.6.0-alt10.1.noarch.rpm |grep '^-[^-]'
-bzip2
-coreutils
-findutils
-gzip
-rsync

В сизифе это явочным порядком исправлено, хотя #12974 тоже объявлено FIXED -- по
идее, можно вернуть спек к состоянию 0.6.0-alt10.

Впрочем, я уже свалил на mkimage. :)