[devel] buildreqs

[devel] buildreqs

[Ivan Zakharyaschev]

Вот такие зависимости были записаны в spec-file:

packagereq: building requires list: libbfd libpam libpam-devel
openssl-devel perl

Не лишний ли libbfd, может его надо включить в список стандартных?


Еще предложение: можно ли buildreqs научить выявлять статическую линковку
с glibc (чтобы знать, можно ли пакет собирать для i586 в системе с glibc
для i686)?

-- 
Best regards,
	Ivan Z.

_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] buildreqs

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

On Sat, Mar 03, 2001 at 02:21:23PM +0300, Ivan Zakharyaschev wrote:
> Вот такие зависимости были записаны в spec-file:
> 
> packagereq: building requires list: libbfd libpam libpam-devel
> openssl-devel perl

libbfd и libpam - лишние.

> Не лишний ли libbfd, может его надо включить в список стандартных?

Mea culpa.
У меня в CVS это все сделано.
Сегодня упакую и выложу новую версию.

> Еще предложение: можно ли buildreqs научить выявлять статическую линковку
> с glibc (чтобы знать, можно ли пакет собирать для i586 в системе с glibc
> для i686)?

Не совсем понятно. Было бы здорово эту мысль развить.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [devel] buildreqs

[Ivan Zakharyaschev]

On Sun, 4 Mar 2001, Dmitry V. Levin wrote:

> On Sat, Mar 03, 2001 at 02:21:23PM +0300, Ivan Zakharyaschev wrote:

> > Еще предложение: можно ли buildreqs научить выявлять статическую
> линковку
> > с glibc (чтобы знать, можно ли пакет собирать для i586 в системе с
> glibc
> > для i686)?
>
> Не совсем понятно. Было бы здорово эту мысль развить.

Попробую. Хотя я тоько теоретически понимаю, что такое динамическая и
статическая линковка, и зачем она нужна. Я имею в виду вот что: buildreqs
следит за тем, что происходит во время сборки, к каким файлам,
библиотекам, архивам происходят обращения. Если buildreqs замечает, что
происходят обращения к архивам, используемым для статической линковки с
glibc, то записывается информация об этом в spec-файл в виде комментария.
Чтобы packager знал, что собирать он может пакет только для своей
архитектуры. Buildreqs может вести себя и строже и не полагаться на
совесть packager'а, а посмотреть на то, для какой архитектуры собрана
установленная glibc, и записать это явно в spec-файл в тэг, например,

BuildArchitecture: i686

Тогда у него, наверное, возникнут проблемы при попытке сделать
rpm -bb --target i586.

Но этот вариант плох тем, что если этот spec-файл попадет на другую
системус другой архитектурой, то эта информация он может стать неверной.

Можно добавлять в spec-файл таких пакетов

BuildArchitecture: %(rpm -q glibc-devel --queryformat=%%{ARCH})

или еще как-нибудь выразить информацию, полученную buildreqs
(ввести специальный макрос, проверяющий соответствие target и архитектуры
glibc; встроить проверку в rpm и т.д.)

А ведь, наверное, могут аналогичные проблемы наблюдаться и при статической
линковке не только с glibc, но и c другими библиотеками для не тех
архитектур (несовпадающих с target)? Можно за всеми статическими
линковками, производимыми при сборке следить, определить специальный
макрос типа %needsSameArch ...

-- 
Best regards,
	Ivan Z.

_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] buildreqs

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]

On Sun, Mar 04, 2001 at 06:40:10PM +0300, Ivan Zakharyaschev wrote:
> > > Еще предложение: можно ли buildreqs научить выявлять статическую
> > линковку
> > > с glibc (чтобы знать, можно ли пакет собирать для i586 в системе с
> > glibc
> > > для i686)?
> >
> > Не совсем понятно. Было бы здорово эту мысль развить.

<skip>

> А ведь, наверное, могут аналогичные проблемы наблюдаться и при статической
> линковке не только с glibc, но и c другими библиотеками для не тех
> архитектур (несовпадающих с target)? Можно за всеми статическими
> линковками, производимыми при сборке следить, определить специальный
> макрос типа %needsSameArch ...

Я все равно не понимаю.
Тот факт, что пакет был собран на архитектуре, скажем, i686, еще не значит
(более того, скорее всего не значит), что он не может быть собран на
архитектуре i585; при этом совершенно не важно, для какой конкретно
архитектуры были собраны gcc, glibc, zlib, ... - все те пакеты, код из
которых мог попасть в исполняемые файлы собираемых пакетов. Это важно
только для бинарных пакетов, BuildRequires тут не причем.

А тот факт, что все пакеты, использующие gcc при сборке, втягивают в
исполняемые файлы всякие crt*.o, делает не менее 90% пакетов дистрибутива
зависимыми от архитектуры сборки самого gcc.

Не вижу пока что никакой практической пользы от попытки все это
отслеживать.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [devel] buildreqs

[Ivan Zakharyaschev]

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