From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: ALT Devel discussion list References: <20070923214814.GP5297@solemn.turbinal> <20070924203114.GC5297@solemn.turbinal> <20070924210455.GC20209@basalt.office.altlinux.org> <20070924214006.GG5297@solemn.turbinal> <20070924223021.GI5297@solemn.turbinal> From: Sergey Bolshakov Date: Tue, 25 Sep 2007 03:02:20 +0400 In-Reply-To: <20070924223021.GI5297@solemn.turbinal> (Alexey Tourbin's message of "Tue, 25 Sep 2007 02:30:21 +0400") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.5-b28 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Subject: Re: [devel] rpm-build 4.0.4-alt78+ RC X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2007 23:02:22 -0000 Archived-At: List-Archive: List-Post: >>>>> "Alexey" == Alexey Tourbin writes: > On Tue, Sep 25, 2007 at 02:14:16AM +0400, Sergey Bolshakov wrote: >> >> Я нахожу это неприемлемым. >> >> Предлагаю удалить зависимость на /usr/bin/tclsh из rpm-build-tcl, >> >> > Эту зависимость удалять нельзя, поскольку работоспособность >> > rpm-build-tcl напрямую связана с наличием /usr/bin/tcl. >> > (Во всех случаях, кроме одного единственного -- сборка самого tcl, >> > где используется переопределение RPM_TCLSH). >> >> Такой подход делает невозможным перенос tcl на другие архитектуры, >> поскольку (по условию) /usr/bin/tclsh там ещё не существует. > Такой подход также делает невозможным перенос perl-base на другие > архитектуры (который входит в basesystem), где /usr/bin/perl ещё не > существует. А также python-base (который привязан к rpm-build). > В общем, это условие слишком абстрактно. Для каждой конкретной > архитектуры всё равно приходится делать bootstrap, и там ситуация > на первых порах бывает покруче, чем недоступность какого-то > интерпретатора. Даже неудобно тебе это объяснять. Мил человек, это мне неудобно тебе объяснять -- негоже создавать геморрой на пустом месте. Я как бы немножко помню, во что выливается бутстрап на другую архитектуру и не стану его создавать там, где могу не создавать. Разумеется, с перлом ты волен делать что тебе вздумается. >> С другой стороны, пакеты, содержащие модули tcl и заселявшие >> /usr/{lib,share}/tcl, содержали в сборочных чрутах /usr/bin/tclsh >> через tcl-devel, остальные либо содержали явную зависимость на >> tcl, либо не предоставляли по результатам сборки зависимостей вида >> tcl(xxx) -- ну и пусть их, уважаемым майнтайнерам виднее. >> >> Короче, я ещё раз предлагаю убрать эту зависимость. > Здесь я не совсем понял. > Однако предлагаю обдумать ещё раз следующее утверждение: > В rpm-build-tcl НУЖНА зависимость на /usr/bin/tclsh КРОМЕ ОДНОГО > ЕДИНСТВЕННОГО СЛУЧАЯ -- сборки самого tcl. Иначе запуск скриптов > /usr/lib/rpm/tcl.{req,prov} ничем не гарантирован -- он просто > обломится. Вариант c [ -x /usr/bin/tclsh ] is not an option. > Зависимости либо ищутся, либо явно отключены. Проверки доступности > интерпретатора больше нету в принципе. Ну так rpm-build-tcl из rpm-build нынче вынесен, и появиться там он теперь может либо в паре с tcl-devel, либо по явному требованию -- ну так что мешает майнтайнеру явно же обеспечить наличие tclsh в билдруте ? >> Я, видимо, ответственнен за бОльшую часть tcl-related и не вижу >> проблемы в добавлении buildreq(pre): rpm-build-tcl во все такие >> пакеты. Вообще, уважаемые майнтейнеры, эта тема Вас хоть >> сколько-нибудь интересует ? > Не надо целиком замыкать на себя какую-то группу пакетов. Рано или > поздно может появиться человек, который будет что-то собирать, и это > будет зудеть, и с этом ничего нельзя будет сделать. С другой стороны, > это дает возможность думать, что нужно дать другим людям, которые не > сильно-то в теме. В случае с перлом таким человеком стал lav@. Не буду. --