From: "Eugene Ostapets" <eostapets@gmail.com> To: "ALT Devel discussion list" <devel@lists.altlinux.org> Subject: Re: [devel] rpm-build-compat Date: Sun, 14 Jan 2007 02:09:48 +0200 Message-ID: <e12fd2db0701131609n130c6855g659041cab085242c@mail.gmail.com> (raw) In-Reply-To: <20070113234100.GA31274@basalt.office.altlinux.org> 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
next prev parent reply other threads:[~2007-01-14 0:09 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-01-13 12:46 [devel] mgetty x86_64 Денис Смирнов 2007-01-13 17:27 ` Anton Gorlov 2007-01-13 19:00 ` Hihin Ruslan 2007-01-13 19:27 ` Dmitry V. Levin 2007-01-13 19:56 ` Hihin Ruslan 2007-01-13 20:00 ` Dmitry V. Levin 2007-01-13 21:05 ` Sergey Y. Afonin 2007-01-13 21:21 ` Dmitry V. Levin 2007-01-13 22:02 ` Sergey Y. Afonin 2007-01-13 22:26 ` Alexey I. Froloff 2007-01-21 11:02 ` [devel] /lib(64)?/mkinitrd Sergey Vlasov 2007-01-21 11:46 ` Dmitry V. Levin 2007-01-13 21:33 ` [devel] mgetty x86_64 Hihin Ruslan 2007-01-13 21:45 ` Anton Gorlov 2007-01-13 22:28 ` Alexey I. Froloff 2007-01-13 22:38 ` Eugene Ostapets 2007-01-13 22:54 ` Pavlov Konstantin 2007-01-13 23:23 ` [devel] rpm-build-compat Dmitry V. Levin 2007-01-13 23:32 ` Eugene Ostapets 2007-01-13 23:41 ` Dmitry V. Levin 2007-01-14 0:09 ` Eugene Ostapets [this message] 2007-01-14 0:34 ` Dmitry V. Levin 2007-01-14 1:05 ` Vitaly Lipatov 2007-01-14 1:29 ` Dmitry V. Levin 2007-01-14 14:43 ` Vitaly Lipatov 2007-01-14 15:03 ` Dmitry V. Levin 2007-01-14 17:23 ` Sergey Y. Afonin 2007-01-14 17:36 ` Alexey I. Froloff 2007-01-14 17:38 ` Dmitry V. Levin 2007-02-04 21:28 ` [devel] [wiki] условное определение макросов Michael Shigorin 2007-02-05 22:50 ` Dmitry V. Levin 2007-01-14 10:28 ` [devel] rpm-build-compat Sergey Y. Afonin 2007-01-14 11:45 ` Dmitry V. Levin 2007-01-14 17:37 ` Sergey Y. Afonin 2007-01-14 17:29 ` Alexey I. Froloff 2007-01-13 20:03 ` [devel] mgetty x86_64 Eugene Ostapets 2007-01-13 20:22 ` Dmitry V. Levin 2007-01-13 21:51 ` Eugene Ostapets 2007-01-13 19:29 ` Konstantin A. Lepikhov 2007-01-13 19:32 ` [devel] cdrecord Dmitry V. Levin 2007-01-13 19:57 ` Hihin Ruslan 2007-01-14 21:06 ` Konstantin A. Lepikhov 2007-01-13 19:35 ` [devel] mgetty x86_64 Anton Gorlov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=e12fd2db0701131609n130c6855g659041cab085242c@mail.gmail.com \ --to=eostapets@gmail.com \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git