$ apt-cache depends spt spt-0.6.0-alt10 Depends: hasher >= 1.2.1 Depends: bzip2 Depends: coreutils Depends: findutils Depends: gzip Depends: installer-stage2 Depends: rsync Depends: sh installer-stage2 вытягивает xorg, alterator и маленькую тележку всего остального. Я не могу считать, что это проблема spt, поскольку в Requires: такой зависимости нет и для скриптов указано %set_findreq_skiplist %_datadir/%name/* %set_findprov_skiplist %_datadir/%name/* -- но также и не понимаю, откуда именно взялась эта диверсия недели номер два.
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. :)
