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

[Alexey Morozov]

On Tue, Mar 15, 2005 at 09:58:14PM +0300, Andrey Orlov wrote:
> > Андрей, речь про _сборочную_ зависимость.
> > Про зависимости "бинарного пакета" речи и не идет, там, кажется, сейчас
> > все корректно с логической точки зрения.
> 
> Я и говорю про ___сборочную___ зависимость. Так вот. Сборочная зависимость.
> 
> 1. Если пакет будет персобран не с тем питоном, он будет неработоспобен.
> Как минимум, потому, что модули лягут не в тот каталог.
Slow. Slow down.

Если "пакет будет пересобран не с тем питоном", то ничего страшного
априори не произойдет. Потому что в нынешней ситуации все (порядочные
мэйнтэйнеры) пользуются для составления списка файлов или
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. 
:-) Попробую. (С некоторой досадой) Слушай, а это же придется читать то,
что мы там с тобой написали, да?

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: отсутствует
Url     : http://lists.altlinux.org/pipermail/devel/attachments/20050316/b2283cdf/attachment.bin