Re: [devel] buildreqs

[Ivan Zakharyaschev <vanyaz@mccme.ru>]

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)?
> > >
> > > Не совсем понятно. Было бы здорово эту мысль развить.
>
> <skip>

> Я все равно не понимаю.
> Тот факт, что пакет был собран на архитектуре, скажем, 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