On Tue, Sep 25, 2007 at 03:02:20AM +0400, Sergey Bolshakov wrote:
>  >> Такой подход делает невозможным перенос tcl на другие архитектуры,
>  >> поскольку (по условию) /usr/bin/tclsh там ещё не существует.
> 
>  > Такой подход также делает невозможным перенос perl-base на другие
>  > архитектуры (который входит в basesystem), где /usr/bin/perl ещё не
>  > существует.  А также python-base (который привязан к rpm-build).
> 
>  > В общем, это условие слишком абстрактно.  Для каждой конкретной
>  > архитектуры всё равно приходится делать bootstrap, и там ситуация
>  > на первых порах бывает покруче, чем недоступность какого-то
>  > интерпретатора.  Даже неудобно тебе это объяснять.
> 
> Мил человек, это мне неудобно тебе объяснять -- негоже создавать
> геморрой на пустом месте. Я как бы немножко помню, во что выливается
> бутстрап на другую архитектуру и не стану его создавать там, где могу
> не создавать. Разумеется, с перлом ты волен делать что тебе вздумается.

Просто проблема с tcl далеко не первична, если речь идет о бутстрапе,
тем более на уровне rpm-зависимостей, а не более суровых фактических
зависимостей.  (Но rpm-зависимости всё же в первом приближении
мимикрируют "суровые" настоящие зависимости, для чего они и нужны.)

Хорошо.  Делай что хочешь.  Отмечу лишь следующее.

В предолженном мной варианте я брал часть ответственности за Tcl
на себя.  То есть если что-либо идет на перекосяк, то я берусь
в какой-то степени это разруливать, вплоть до возвращения в
rpm-build-tcl в базовую сборочную среду (но уже вместе с /usr/bin/tclsh,
то есть в моём варианте!).

Если мой вариант не катит, то я ответственность с себя снимаю.
Я уже писал, что сломаться может гораздо больше.