[devel] Переход на новый python

[Andrey Orlov]

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 ---
----------------------------------------