[devel] Сборка в среде ALT для SUSE

Andrei Bulava =?iso-8859-1?q?abulava_=CE=C1_altlinux=2Eru?=
Вт Ноя 22 12:55:15 MSK 2005


Vitaly Lipatov wrote:
> On Monday 21 November 2005 21:58, Денис Смирнов wrote:
> 
>>Задача -- надо собрать пакет под SUSE, потому что этого хочет
>>клиент. Клиент всегда прав, поэтому придётся собрать.
>>
>>Но SUSE мне нужна как зайцу пятый стоп-сигнал, и ставить её
>>мне ну совершенно не улыбается.
>>
>>Можно ли собрать в ALT пакет для другой системы, не ставя саму
>>систему?
>>
>>Или просто сотворить chroot с SUSE?
> 
> Давайте обсудим, мне тоже интересно:
> 1. У меня установленная SuSE, могу дать shell

У меня CentOS 4.2.

> 2. Я почти дособирал пакеты, чтобы заставить работать на 
> репозитарии из SuSe hasher.

Уже есть собранные пакеты, чтобы hasher работал на репозитарии из CentOS
4.2. Маленький нюанс: для бутстрапа из src.rpm я использовал
вышеупомянутый установленный CentOS 4.2, т.к. надо было хоть как-то
собрать rpm fakeroot.

> 3. Я собираю пакет, который, будучи установленный в "чужую" 
> систему, позволяет собирать там пакеты практически по альтовским 
> спекам.

С этим у меня не было желания заморачиваться - уж слишком отличается
привычный по ALT rpm от того, что в RHEL4. И это напрягает, причём
довольно серьёзно.

Из переписки с ldv@ и собственных изысканий я узнал, что некоторые фичи
hasher вообще не будут работать на "чужих" rpm, а некоторые - глючат по
не выясненным пока что причинам.

Не будут работать hsh --repackage-source, как и макрос %buildhost - эти
фичи вряд ли присутствуют в rpm, используемых за пределами ALT и
Openwall Linux.

Из проблем в CentOS 4.2, причины которых пока не ясны - со сценариями
rpm (секции %pre, %post и т.п.) для пакетов, устанавливаемых указанием
опции hsh --pkg-init-list: они не запускаются :-( В итоге в
chroot-системе как минимум не хватает пользователей, создаваемых при
установке таких пакетов, хотя в данный момент для меня это не blocker.

> Цель: сделать сборочный сервер и технологию к нему, который 
> позволит собирать пакет под любой дистрибутив. Мы это используем 
> для WINE например. Можно как-то координироваться...

Я могу открыть свои наработки по CentOS 4.2. Но вашего оптимизма по
поводу сборочного сервера и технологии под _любой_ дистрибутив я не
разделяю. Достаточно того, что CentOS 4.2 и его матрица, RHEL4 U2
банально сломаны как aptbox'ы и сборочные системы:

1) систему нельзя установить в aptbox без вот такого чуда:

$ rpm -p -q --provides hasher-fake-provides-rh-1.0-alt1.EL4.2.noarch.rpm

perl(Search::Dict) = 1.02

иначе в aptbox не ставится perl из-за несоответствия своих собственных
Requires и Provides (требует perl(Search::Dict) с версией, а
предоставляет - без).

2) невозможно использовать поставляемый на диске двоичный rpm libtool
(ага, а он нужен для сборки fakeroot);

3) и самое дикое: я далеко не с первого раза понял, что в
системообразующем пакете rpm-build напрочь отсутствуют зависимости,
которые я в конце концов навешал на ещё одно чудо:

$ rpm -p -qR hasher-build-rh-1.0-alt1.EL4.2.noarch.rpm
autoconf
automake
bzip2
diffutils
elfutils
libtool
libtool-libs
make
redhat-rpm-config

Насчёт redhat-rpm-config и elfutils - был вообще детектив, когда я
разбирался, почему собранные в виртуальной машине с CentOS пакеты так
радикально (двоично) отличаются от пакетов, что я собирал в hasher.

Меня уже отчитывали за "удаффщину" в рассылке, но в данном случае слов
просто нет - сплошные цитаты.

-- 
// AB1002-UANIC




Подробная информация о списке рассылки Devel