From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Andrey Orlov To: ALT Devel discussion list Subject: Re: [devel] =?koi8-r?b?8MXSxcjPxCDOwSDOz9fZyg==?= python Date: Tue, 15 Mar 2005 21:58:14 +0300 User-Agent: KMail/1.7.1 References: <200503091049.10104.cray@neural.ru> <200503142329.45292.cray@neural.ru> <20050315170642.GI2741@pyro.hopawar.private.net> In-Reply-To: <20050315170642.GI2741@pyro.hopawar.private.net> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200503152158.15291.cray@neural.ru> X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2005 18:58:24 -0000 Archived-At: List-Archive: List-Post: 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 --- ----------------------------------------