From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivan Zakharyaschev To: Subject: Re: [devel] buildreqs In-Reply-To: <20010305044920.B19403@LDV.fandra.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=koi8-r Content-Transfer-Encoding: 8BIT Sender: devel-admin@linux.iplabs.ru Errors-To: devel-admin@linux.iplabs.ru X-BeenThere: devel@linux.iplabs.ru X-Mailman-Version: 2.0 Precedence: bulk Reply-To: devel@linux.iplabs.ru List-Help: List-Post: List-Subscribe: , List-Id: IPLabs Linux Team Developers mailing list List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 5 Mar 2001 21:31:22 +0300 (MSK) Date: Mon, 5 Mar 2001 21:31:22 +0300 (MSK) Archived-At: List-Archive: List-Post: On Mon, 5 Mar 2001, Dmitry V. Levin wrote: > On Sun, Mar 04, 2001 at 06:40:10PM +0300, Ivan Zakharyaschev wrote: > > > > Еще предложение: можно ли buildreqs научить выявлять статическую > > > линковку > > > > с glibc (чтобы знать, можно ли пакет собирать для i586 в системе > с > > > glibc > > > > для i686)? > > > > > > Не совсем понятно. Было бы здорово эту мысль развить. > > > Я все равно не понимаю. > Тот факт, что пакет был собран на архитектуре, скажем, i686, еще не > значит > (более того, скорее всего не значит), что он не может быть собран на > архитектуре i585; при этом совершенно не важно, для какой конкретно > архитектуры были собраны gcc, glibc, zlib, ... - все те пакеты, код из > которых мог попасть в исполняемые файлы собираемых пакетов. Это важно > только для бинарных пакетов, BuildRequires тут не причем. BuildRequires как свойство source-пакета тут действительно не причем. Я вот о чем: когда-то у нас возникали проблемы, связанные с тем, что программы из некоторых бинарных пакетов, собранных для i586 на системе с glibc для i686, на самом деле не работали на i586, несмотря на название пакета (i586.rpm). И packager об этом не подозревал: он делал себе rpm -bb --target=i586, получал без всяких сообщений об ошибках пакет и распространял его как i586.rpm. Теперь мы знаем, что архитектура сборки glibc накладывает ограничение на target для пакетов, статически линкующихся с ней. Пополнение этого списка (пока список из одной glibc) -- не дело автоматики. Ей же я предлагаю поручить обнаружение того факта, что пакет при сборке производит статическую линковку с glibc. Это первая часть предложения (реализация которой у меня уже вызывает вопрос: можно ли на основе данных от starce понять, что происходит именно статическая линковка). Вторая часть касается того, что же делать с полученной информацией. Можно просто предупредить packager'а (мол, если Вы соберете этот пакет для архитектуры отличной от архитектуры glibc, то не факт, что оно заработает на этой target-архитекуре) -- сам packager может об этом и не задуматься. Можно попытаться более строго записать это для rpm. Просто BuildArchitecture: i686 не подойдет, потому что: > Тот факт, что пакет был собран на архитектуре, скажем, i686, еще не > значит > (более того, скорее всего не значит), что он не может быть собран на > архитектуре i585; при этом совершенно не важно, для какой конкретно Тогда пытаемся написать что-нибудь такое, что бы заставляло rpm при попытке собрать этот пакет кем-нибудь для некоторой target-архитектуры проверить, подходит ли архитектура имеющейся в системе glibc для этой цели (сборки статически слинкованной с ней программы для target-архитектуры). Эта проверка не подразумевает со сотороны rpm никакого "думания", просто сравнение названий архитектур по заранее определенным правилам. Самая простая иллюстрация этого (может, реально не работающая) -- добавление тэга вида: BuildArchitecture: %(rpm -q glibc-devel --queryformat=%{ARCH}) Тут уже в качестве значения не что-то постоянное, оно вычисляется каждый раз перед началом сборки (вызовом rpm -q glibc-devel ... ). Несоответствие значений --target= и BuildArchitecture: должно помешать собраться "битому" пакету у несведущего packager'а. Причем тут buildreqs? Во-первых, это все делается теми же средствами -- слежением с помощью starce. Во-вторых, совпадают не только средства, но и цель всего этого: предотвращение сборки "битых" пакетов плохо осведомленными packager'ами (такими в какой-то степени можно считать всех). "Битых" значит неработающих, несоответствующих своему названию, не таких, какими их предполагал первоначальный packager. BuildRequires служит для того же: первоначальный packager собрал пакет, посмотрел, что при сборке ему было нужно то-то, то-то и то-то, записал это, проверил, что все работает так, как он ожидает, и выпустил src.rpm. Потом кто-то его взял, сделал rpm --rebuild, а у него нет чего-то из BuildRequires и он не собирается. А если BuildRequires не было, он бы (возможно) собрал, ничего не заметив, и получил бы бинарный пакет с программами, работающими не так, как ожидал первоначальный packager (maintainer) пакета. > А тот факт, что все пакеты, использующие gcc при сборке, втягивают в > исполняемые файлы всякие crt*.o, делает не менее 90% пакетов > дистрибутива > зависимыми от архитектуры сборки самого gcc. > > Не вижу пока что никакой практической пользы от попытки все это > отслеживать. Не надо все тянуть -- надо определить библиотеки, для которых это важно. Про glibc мы вроде это поняли. -- Best regards, Ivan Z. _______________________________________________ Devel mailing list Devel@linux.iplabs.ru http://www.logic.ru/mailman/listinfo/devel