From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: devel@lists.altlinux.org References: <20070909181938.GR6051@solemn.turbinal> <20070909194513.GT6051@solemn.turbinal> <20070909222824.GW6051@solemn.turbinal> <20070910215227.GF6051@solemn.turbinal> From: Sergey Bolshakov Date: Tue, 11 Sep 2007 13:49:21 +0400 In-Reply-To: <20070910215227.GF6051@solemn.turbinal> (Alexey Tourbin's message of "Tue, 11 Sep 2007 01:52:27 +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 -- remove rpm-build-tcl? 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: Tue, 11 Sep 2007 09:49:23 -0000 Archived-At: List-Archive: List-Post: >>>>> "Alexey" == Alexey Tourbin writes: > On Mon, Sep 10, 2007 at 02:46:18PM +0400, Sergey Bolshakov wrote: >> Вынос rpm-build-tcl из базовой сборочной среды -- это упование >> на то, что майнтайнер впишет его в buildreq(pre). > Это не совсем так. См. ниже. >> Как нетрудно убедиться, это не сработало (в варианте buildreq: tcl) >> даже с автором rpm-build-tcl и sandman. >> >> Последствия выноса -- некоторая деградация технологии сборки для >> tcl, бонус -- убыстрение процесса сборки, в отдалённом будущем -- >> вычищение базы apt от пары-тройки сотен сущностей. >> 'Техносноб' (с) во мне внёс бы tcl в rpm-build, конформист -- >> вынес бы умирающее тело на воздух. > Можно обсудить вариант выноса rpm-build-tcl из базовой сборочной среды. > Мой старый аргумент ЗА сохранение rpm-build-tcl состоит в следующем: > Tcl скрипты встречаются тут и там, и для того, чтобы результат поиска > зависимостей не "плавал" в зависимости от укомплектовки buildroot'а, > а также в интересах syntax check, нужно иметь всегда работающий tcl.req > и tcl.prov. > Теперь следующие обстоятельства отменяют этот аргумент: в Tcl фактически > нет понятие syntax check; поиск зависимостей сводится чисто к выполнению > кода; поэтому он годится для модулей, но совершенно не годится для > скриптов. Следовательно, как зависимости скриптов, так и их syntax > check, это по сути моя преждевременная идея от недопонимания специфики > Tcl. > Если просто оторвать rpm-build-tcl от rpm-build, то, естественно, > сломается некоторое (довольно большое) число пакетов. Вариант решения > этой проблемы состоит в том, чтобы подшить rpm-build-tcl в зависимости > к tcl-devel. Тогда все пакеты, у которых сейчас в билдрут встаёт > tcl-devel, заведомо не должны сломаться от этой перетасовки. К этому > классу пакетов относятся как минимум все компилируемые tcl extensions. > Я грепю логи успешно собравшихся пакетов, чтобы показать, что пакеты > tcl и tcl-devel на самом деле, в большей половине случаев, соседствуют > в билдруте. Такое положение дел объясняется тем обстоятельством, что стандартные для расширений tcl (необязательно бинарных) сборочные скрипты (именуемые TEA -- tcl extension architecture) опираются на информацию из /usr/lib/tclConfig.sh Тем не менее, нет никаких способов форсировать применение этой самой TEA, и вполне могут существовать расширения, для которых наличие tcl-devel в билдруте избыточно. [skipped] > Значит, относительно безопасная перетасовка rpm-build-tcl состоит > в следующем: 1) в любом случае добавить Reqruies: tcl в rpm-built-tcl; > 2) в любом случае добавить Requires: rpm-build-tcl в tcl-devel; > 3) возможно, убрать Requires: rpm-build-tcl из rpm-build. > Чтобы понять, насколько эта перетасовка действительно безопасна, > желательно выборочно проверить те пакеты из этого списка, у которых > в билдруте tcl-devel не стоит -- как минимум, на предмет использования > макросов типа %_tcllibdir. Если таковые найдутся, их несложно будет починить. Бишь, обсуждаемый вариант вполне возможен, осталось выяснить, зачем такая перетасовка нужна -- мне кажется, мы несколько увлеклись процессом и потеряли из виду желаемый результат (я, по крмере). 1) не может иметь фатальных последствий; 2) и далее -- я не могу сделать выбора, не представляя шкалы приоритетов. --