Re: [devel] Python 2.6: task #16528

[Alexey Tourbin <at@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 3019 bytes --]

On Sun, Nov 29, 2009 at 03:38:53AM +0200, Led wrote:
> On Sunday, 29 November 2009 03:32:02 Alexey Tourbin wrote:
> > On Sun, Nov 29, 2009 at 03:14:13AM +0200, Led wrote:
> > > On Sunday, 29 November 2009 02:51:52 Alexey Tourbin wrote:
> > > > On Sun, Nov 29, 2009 at 01:01:36AM +0200, Michael Shigorin wrote:
> > > > > On Wed, Nov 25, 2009 at 10:37:57AM +0300, Alexey Tourbin wrote:
> > > > > > Если от двух питонов решили отказаться, то есть смысл изменить
> > > > > > зависимости вида python2.X(...) на просто python(...).  Потому
> > > > > > что скрипты на питоне по идее не зависят от версии питона.
> > > > >
> > > > > Лёш, ты серьёзно?  Вообще-то с совместимостью там так себе.
> > > >
> > > > python2.5 -> python2.6 пакеты пересобираются as is.
> > > > Почему у отдельно взятого скрипта должны измениться зависимости
> > > > на питон, если сам скрипт не изменился?
> > > >
> > > > Фактически же часть пакетов сейчас пересобирается почему?
> > > > Потому что надо чтобы у них поменялись зависимости с 2.5 на 2.6.
> > > > А в остальном в этих пакетах ничего не меняется.
> > >
> > > *.pyc меняются
> >
> > Если это очень одинокий скрипт то у него *.pyc нету.
> > Например /usr/bin/asciidoc.
> >
> > Сейчас кстати *.pyc вообще не создает зависимостей.  Зато создаются
> > зависимости на /usr/lib/python2.5/site-packages и libpython2.5.so.1 (для
> > всех питоновских модулей, которые становятся в стандартный каталог и/или
> > компилируются).  То есть теперь имеются другие достаточно надёжные
> > способы обеспечить физическую целостность питновского хозяйства при
> > миграции на новый питон.  И они включаются как раз тогда когда надо.
> 
> Дело не в зависимостях. Если *.pyc не перекомпилированы, а интерпритатор 
> сменил версию (2.5 -> 2.6), то *.pyc превращаются в неиспользуемый балласт 
> (AFAIR).

Можно контролировать совместимость по *.pyc.  В *.pyc файле содержится
версия питона, для которой он подходит (напр. 2.5 или 2.6).  Тогда для
каждого *.pyс файла можно генерировать зависимость типа
Requires: python-bytecode-version = 2.5 (или 2.6).

Это открывает интересные возможности при миграции на новый питон.
А именно, на первой стадии пересборки новый питон может предоставлять
условную совместимость со старым байткодом:
Provides: python-bytecode-version = 2.5
Provides: python-bytecode-version = 2.6

Это позволяет быстрее провести переехать на новый питон, пересобрав
только те пакеты, которые действительно необходимо пересобрать (как
минимум по сонейму).  На второй стадии совместимость со старым питоном
удаляется, остаётся только
Provides: python-bytecode-version = 2.6

тогда потребуется пересобрать уже все пакеты со старым байткодом.

Можно пойти ещё дальше и попробовать сделать чтобы на первой стадии
новый питон поддерживал старый noarch каталог site-packages.

В любом случае это открывает более интересные возможности, чем просто
пересобрать _все_ пакеты которым _хоть что-то_ нужно от питона.
Даже очень одинокие скрипты.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]