[devel] rpm-build-compat

Eugene Ostapets =?iso-8859-1?q?eostapets_=CE=C1_gmail=2Ecom?=
Вс Янв 14 03:09:48 MSK 2007


14.01.07, Dmitry V. Levin<ldv altlinux.org> написал(а):
> On Sun, Jan 14, 2007 at 01:32:57AM +0200, Eugene Ostapets wrote:
> > 14.01.07, Dmitry V. Levin<ldv altlinux.org> написал(а):
> > > Второй раз на те же грабли.
> > >
> > > Так, давайте договоримся не переопределять системные rpm-макросы файлами
> > > из /etc/rpm/macros.d/ без письменного согласия мантейнера файла
> > > /usr/lib/rpm/macros.
> > Давайте договоримся о "preinstalled" конфигурациях hasher!!!
> Простите, а при чём тут hasher?
А у нас есть другой механизм рекомендованой сборки пакетов???
>
> > Я вынужден использовать собственный пакет rpm-build, который Required:
> > x86_64-compat, содержащий один-единственный файл
> > /etc/tpm/zzz_fake64build с уже озвученым содержимым....
> > Есть два варианта:
> > 1) Мы делает libexecdir == libdir
>
> Один уже сделал.
> Вы будете учиться на чужих ошибках или предпочитаете на своих?
Все, (для не умеющих читать - ВСЕ мои пакеты вылечились для платформы
x86_64 с использованием ошибочной версии etersoft-build-utils). Я знаю
что бывают пакеты, для которых требуется интелект, подхватих парочку
таких из orphaned я это оценил на своей шкуре, но... Возможность на
автомет проверить пакеты на САМУЮ ТИПИЧНУЮ ошибку облегчит жизнь
майнтейнерам... Эта ошибка НЕ зависит от майнтейнера... Она диктуется
autotools-howto и политикой самого распространеного дистрибутива
линукс - RedHat(Fedora), который плюет на FHS и поддерживает
существование LIBEXECDIR
>
> > 2) Мы реализуем в hasher возможность задания "predefined"
> > add_packagelist, куда любой майнтейнер включает x86_64-compat и решает
> > для себя проблему (i386) %_libdir==%_libexecdir, но (x86_64)
> > %_libexecdir != %_libdir
>
> Вы действительно полагаете, что проблему i386 != x86-64 можно решать таким
> способом?
99% проблем именно так решается, у меня более сотни пакетов, из
которых почти 40 не собирались на 64 бит платформе из-за этого бага...
>
> Мантейнер, который использует макрос %_libexecdir, полагается на то, что
> его значение одинаково на всех платформах, на которых одинаково значение
> макроса %_bindir.
При чем тут майнтейнер??? Использование %_libexecdir прописывается
авторами пакета в секции install... А вот идеологи дистрибутива решают
чему равняется libexecdir... В некоторых итрибутивах она всегда
равняется %_libdir, где-то она равна /usr/libexecdir, а вот у нас она
зависит от платформы... У нас вообще странная поддержка платформ не
равных i586... Точнее этой поддержки нет... ВООБЩЕ нет!!!(Пусть
кто-нибудь попробует собрать bootstrap-alt под qemu-arm или что-то
подобное - он сразу поймет что лучше свалить на другой дистрибутив,
чем трахаться с альтом...). И поддержка wine в будущем Мастер 3.1
x86_64 тоже под странным вопросом... Во всех "ведущих" (по карйней мре
известных мне) дистрибутивах есть поддержка biarch и только ALT
заявляет что "biarch -  это миф"...
>
> На что рассчитываете вы, я просто не могу понять.
Я рассчитываю на помощь со стороны вендора... Есть уникальный (я не
знаю аналогов, только SuSE пытается создать что-то подбное) - hasher,
есть типичная ошибка mainstream (связанная в первую очередь с
несогласованностью вендоров), и есть идея - создать механиз
(необязательный, но рекомендуемый для майнтейнеров), который позволит
на этап сборки определить потенциальную ошибку...
> Тоже, наверное, шутите или празднуете.
Мне жаль что Вы уже празднуете и так относитесь к вполне вменяемым
идеям. Наличие Hasher - единственное что позволяет мне использовать
Альт в реальной жизни, "глючный" etersoft-build-utils - то, что
позволяло мне собирать пакеты для Альт во время "перекуров" на
"типичном" железе, но с Вашей позицией у меня возникает желание
последовать за Булавой  и Зубковым - зачем тратить время и силы, если
это никому ненужно и вызывает только поток критики...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets на jabber.ru


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