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

[Andrey Orlov]

On Wednesday 16 March 2005 10:24, Alexey Morozov wrote:
> > 1. Если пакет будет персобран не с тем питоном, он будет неработоспобен.
> > Как минимум, потому, что модули лягут не в тот каталог.
> Slow. Slow down.
> 
> Если "пакет будет пересобран не с тем питоном", то ничего страшного
> априори не произойдет. Потому что в нынешней ситуации все (порядочные

[skip]

У нас видимо, подмена понятий. Итак. Для меня, использующего модуль
b из программы c, после того, как программа c пересобрана с python2.4,
модуль 

> мэйнтэйнеры) пользуются для составления списка файлов или
> INSTALLED_FILES или, на худой конец, %python_libdir, который, как
> несложно понять, привязывается именно к той версии питона, под которой
> происходит сборка пакета. То есть, собираем под python2.3 - пойдет
> в /usr/lib/python2.3 (и зависимость выставится именно на python 2.3).
> Собираем под 2.4 - пойдет в соответствующее место и зависимость
> выставится соответствующая. Тут-то проблем нет. Проблемы могут
> возникнуть, когда старый пакет, несмотря на "собираемость" под новым
> питоном оказывается в итоге неработоспособным (ну, я вижу два случая:
> несоместимость нового питона в синтаксисе или библиотеках).
> Но, кажется, это, скорее, форс-мажор.
> 
> 
> > 2. hasher (вернее apt-get) собирая сборочную среду имеет тенденцию
> > вытаскивать не тот python, который нужен. Т.е. не последний. 
> А вот это, наверное, другая проблема, но, кажется, ты пытаешься
> рубить хвост змея горыныча, вместо того, чтобы рубить (и прижигать еще,
> кажется, надо было) головы. Тогда это так и стоит объявлять:
> 
> due to deficiency of apt/hasher we have to explictly bind...
> 
> > То что я имею проявления этой ошибки дома каждый день - я об этом
> > просто молчу, LDV научил меня с ней бороться, я это уже делаю на автомате.
> Может, вам, эта, собраться вдвоем и родить, гхм, гомункула, который
> будет делать это за вас? ;-)
> 
> > 3. Ну и наконец, собственно элементарная логика - довод лично для меня
> > - я проверил сборку пакета инструментом под названием pythonX.Y, я хочу
> > гарантировать, что будет иметь место сборка именно этой версией.
> 
> > Будет pythonX.Y + 1 (для тех кто в танке: версия питона, минор которой
> > на единицу больше, > чем у питона в предыдущем предложении) - я хочу сам
> > его туда положить. Так что лично в моих пакетах такая зависимость будет
> > всегда - я своими пакетами пользуюсь, и их работоспособность для меня не
> > пустой звук.
> <затихающие звуки гимна здравому смыслу>
> 
> Могу поручиться, что твой любимый писатель в детстве - Жюль Верн.
> 
> А теперь будь добр, изложи все это в полиси. Я, в общем, не против
> такой постановки вопроса, я просто хочу, чтобы это было раз и навсегда
> зафиксировано, и в ответ на будущие инсинуации ты просто сошлешься на
> себя самого. "Он памятник воздвиг..." и все такое прочее.
> 
> 
> > Б) А собственно, что мы выигрываем, убрав зависимость? Робот-пересборщик
> > нужен так и так, сами пакеты не пересобираются. Я вопрос подробно не
> > изучал (сейчас займусь), но если я правильно понял LDV, сложность робота
> > возрастает незначительно, к тому же по любому такая проблема возникает и
> > с другими пакетами. Так что никакого __выигрыша__ убрав зависимость мы
> > не получаем.
> Ну, мне лень думать про ваших гомункулов. Вы уж как-нибудь сами :-)
> 
> > Ну, это верно, но, боюсь, что это мой личный аргумент. Похоже, сообщество
> > в целом предпочитает обновится неоттетсированным пакетом, грохнуть себе 
> > машину и потом писать багрепорты. Это возможный выбор. У меня-то главная
> Фтопку демократию.
> 
> > вопросов, в которых это разжевано. Посмотри пожалуйста наше FAQ,
> > если там __вдруг__ объяснения нет или оно недостаточно разжевано -
> > подвесь багрепорт на rpm-build-python. 
> :-) Попробую. (С некоторой досадой) Слушай, а это же придется читать то,
> что мы там с тобой написали, да?
> 
> 

-- 
WthBstRgrds --
 -- Andrey Orlov --