From: Andrey Orlov <cray@neural.ru> To: ALT Devel discussion list <devel@altlinux.ru> Subject: Re: [devel] Переход на новый python Date: Tue, 15 Mar 2005 21:58:14 +0300 Message-ID: <200503152158.15291.cray@neural.ru> (raw) In-Reply-To: <20050315170642.GI2741@pyro.hopawar.private.net> On Tuesday 15 March 2005 20:06, Alexey Morozov wrote: > On Mon, Mar 14, 2005 at 11:29:44PM +0300, Andrey Orlov wrote: > > > Ну, возможно, следует ограничить привязку > > > python-devel'ом, а версию этуму python-devel'у проставлять только > > > в случае "явной привязки", т.е. --with pythonXY. > > Это уже обсуждалось неоднократно. Если мы хотим иметь набор питоновских пакетов, которые > > работают или не ставятся (так как мантейнеры их не пересобрали), то мы ставим зависимость. > > Андрей, речь про _сборочную_ зависимость. > Про зависимости "бинарного пакета" речи и не идет, там, кажется, сейчас > все корректно с логической точки зрения. Я и говорю про ___сборочную___ зависимость. Так вот. Сборочная зависимость. 1. Если пакет будет персобран не с тем питоном, он будет неработоспобен. Как минимум, потому, что модули лягут не в тот каталог. 2. hasher (вернее apt-get) собирая сборочную среду имеет тенденцию вытаскивать не тот python, который нужен. Т.е. не последний. Сейчас это оканчивается ошибкой сборки, и incominger разбирается с ней. Если зависимость убрать - это будет кончатся пакетом, собранным с неверным питоном. Раньше, я наблюдал это на своих и чужих пакетах не раз. Ошибка была жива по крайней мере два месяца назад, когда очередной раз обломалась сборка пакета в дедале. То что я имею проявления этой ошибки дома каждый день - я об этом просто молчу, LDV научил меня с ней бороться, я это уже делаю на автомате. 3. Ну и наконец, собственно элементарная логика - довод лично для меня - я проверил сборку пакета инструментом под названием pythonX.Y, я хочу гарантировать, что будет иметь место сборка именно этой версией. Будет pythonX.Y + 1 (для тех кто в танке: версия питона, минор которой на единицу больше, чем у питона в предыдущем предложении) - я хочу сам его туда положить. Так что лично в моих пакетах такая зависимость будет всегда - я своими пакетами пользуюсь, и их работоспособность для меня не пустой звук. > Вообще говоря, я, кажется, вижу [гипотетическую] ситуацию, когда > необходима именно сборочная зависимость. Это когда пакет может сломаться > после пересборки в новом окружении. Соответственно, если я правильно А) Может. На переходе 1.52 / 2.0, 2.0 / 2.1, 2.1/2.2, 2.2/2.3 такие случаи были сплошь и рядом. На 2.3/2.4 мы с тобой такого, кажется, почти не заметили. Собственно потому я и повел речь о автоматической пересборке. Б) А собственно, что мы выигрываем, убрав зависимость? Робот-пересборщик нужен так и так, сами пакеты не пересобираются. Я вопрос подробно не изучал (сейчас займусь), но если я правильно понял LDV, сложность робота возрастает незначительно, к тому же по любому такая проблема возникает и с другими пакетами. Так что никакого __выигрыша__ убрав зависимость мы не получаем. > помню, ты именно по этой причине склонил меня к проставлению версии > в сборочной зависимости, чтобы первоначальная пересборка под новую > версию _всегда_ делалась руками, и был, грубо говоря, ответственный > за то, что пакет отправляется в репозиторий с новой версией питона. Ну, это верно, но, боюсь, что это мой личный аргумент. Похоже, сообщество в целом предпочитает обновится неоттетсированным пакетом, грохнуть себе машину и потом писать багрепорты. Это возможный выбор. У меня-то главная претензия другая: как показывает практика, благодаря особенностям apt-get, если я кладу пакет с BuildReq: python-devel то нет никакой гарантии, что я получу пакет, пересобранный именно с python-devel = X.Y. Я могу получить все что угодна: на сегодняшний день, вплоть до python-devel = 2.2. Увы, так собирается сборочная среда. Если эта ошибка будет исправлена - можно что-то обсуждать, хотя все равно, доводы оппонентов базируются на утвержденнии, что наличие такой зависимости делает невозможной автоматическую пересборку. Утверждение, которое, похоже, ложное. Опять-таки - еще не проверял. > Возможно, это достаточный аргумент, но, думаю, его в любом случае стоит > явно выделить в полиси, для того, чтобы не рассусоливать каждый раз, > когда возникает вопрос, а почему мы сделали именно так. Слушай. Я честно говоря устал уже каждый раз лазить в FAQ и перечислять список вопросов, в которых это разжевано. Посмотри пожалуйста наше FAQ, если там __вдруг__ объяснения нет или оно недостаточно разжевано - подвесь багрепорт на rpm-build-python. -- WthBstRgrds -- Андрей Орлов -- --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org --- ----------------------------------------
next prev parent reply other threads:[~2005-03-15 18:58 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-03-09 7:49 Andrey Orlov 2005-03-11 15:43 ` Dmitry V. Levin 2005-03-11 16:08 ` Alexey Morozov 2005-03-11 16:43 ` Dmitry V. Levin 2005-03-13 18:37 ` Mikhail Zabaluev 2005-03-14 8:46 ` Alexey Morozov 2005-03-14 20:29 ` Andrey Orlov 2005-03-15 9:13 ` Mikhail Zabaluev 2005-03-15 17:06 ` Alexey Morozov 2005-03-15 18:58 ` Andrey Orlov [this message] 2005-03-16 6:41 ` Alexey I. Froloff 2005-03-16 7:26 ` Alexey Morozov 2005-03-16 8:53 ` [devel] " Michael Shigorin 2005-03-16 8:58 ` Ivan Fedorov 2005-03-16 7:51 ` [devel] " Andrey Orlov 2005-03-16 8:48 ` Alexey I. Froloff 2005-03-16 11:29 ` Andrey Orlov 2005-03-16 11:43 ` Alexey I. Froloff 2005-03-16 13:11 ` Andrey Orlov 2005-03-17 7:17 ` Alexey I. Froloff 2005-03-17 7:53 ` Andrey Orlov 2005-03-17 8:01 ` [devel] " Michael Shigorin 2005-03-17 20:28 ` Andrey Orlov 2005-03-18 9:05 ` Michael Shigorin 2005-03-17 8:13 ` [devel] " Alexey I. Froloff 2005-03-17 8:37 ` Anton Farygin 2005-03-17 20:26 ` Andrey Orlov 2005-03-16 7:24 ` Alexey Morozov 2005-03-16 8:28 ` Andrey Orlov 2005-03-16 8:46 ` Andrey Orlov 2005-03-16 21:18 ` Mikhail Zabaluev 2005-03-16 21:44 ` Andrey Orlov 2005-03-17 23:33 ` Mikhail Zabaluev 2005-03-18 0:09 ` Andrey Orlov 2005-03-18 8:03 ` Mikhail Zabaluev 2005-03-19 11:39 ` Andrey Orlov 2005-03-19 21:17 ` [devel] apt-rpm issue Dmitry V. Levin 2005-03-13 21:31 ` [devel] Переход на новый python Andrey Orlov 2005-03-14 0:02 ` Dmitry V. Levin 2005-03-14 11:10 ` [devel] " Michael Shigorin 2005-03-14 16:29 ` [devel] " Dmitry V. Levin 2005-03-14 20:43 ` Andrey Orlov 2005-03-14 22:18 ` Alexey I. Froloff 2005-03-14 23:06 ` Andrey Orlov 2005-03-15 6:35 ` Alexey I. Froloff 2005-03-15 8:38 ` Andrey Orlov 2005-03-14 23:12 ` Dmitry V. Levin 2005-03-14 23:19 ` Alexey Rusakov 2005-03-14 23:22 ` Andrey Orlov 2005-03-14 23:40 ` Dmitry V. Levin 2005-03-15 8:09 ` Andrey Orlov 2005-03-29 16:19 ` Dmitry V. Levin 2005-03-29 17:23 ` Вячеслав Диконов 2005-03-30 1:01 ` Ivan Fedorov 2005-03-30 8:36 ` Vitaly Lipatov 2005-03-30 10:57 ` Dmitry V. Levin 2005-03-30 14:02 ` Sergey V Turchin
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=200503152158.15291.cray@neural.ru \ --to=cray@neural.ru \ --cc=devel@altlinux.ru \ /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