[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