[devel] python3.x(qwe) vs python3(qwe)

[devel] python3.x(qwe) vs python3(qwe)

[Евгений Ростовцев]

Привет!

В ходе многочисленных обсуждений я так и не понял, чем хороши
провайдинги python3.x(qwe) и чем плохи python3(qwe).

Ибо в планах всё же есть намерение засунуть в сизиф Python 3. Это
никак не затронет Python 2.6 (...вроде бы...), но кое-какие моменты
нужно обговорить.

-- 
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] python3.x(qwe) vs python3(qwe)

[Денис Смирнов]

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

On Sun, Jan 31, 2010 at 08:48:20AM +0700, Евгений Ростовцев wrote:

ЕР> В ходе многочисленных обсуждений я так и не понял, чем хороши
ЕР> провайдинги python3.x(qwe) и чем плохи python3(qwe).

Это зависит от того будет ли у python3 точно также как и 2 ломаться
совместимость между minor версиями.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Sergey Y. Afonin]

On Sunday 31 January 2010, Денис Смирнов wrote:

> ЕР> В ходе многочисленных обсуждений я так и не понял, чем хороши
> ЕР> провайдинги python3.x(qwe) и чем плохи python3(qwe).
> 
> Это зависит от того будет ли у python3 точно также как и 2 ломаться
> совместимость между minor версиями.

Вряд ли кто это узнает, пока оно не произойдёт... 

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] python3.x(qwe) vs python3(qwe)

[Евгений Ростовцев]

Привет!

> ЕР> В ходе многочисленных обсуждений я так и не понял, чем хороши
> ЕР> провайдинги python3.x(qwe) и чем плохи python3(qwe).
>
> Это зависит от того будет ли у python3 точно также как и 2 ломаться
> совместимость между minor версиями.

В том-то и вопрос состоит: с python 2.6 вышла фигня, что пришлось
собирать пакеты одним громадным заданием. А вот насчёт ломки
совместимости: давайте подумаем, что за механизм может нам помочь
такие разломы ловить индивидуально: при пересборке ли, репокопом ли. И
индивидуально пусть мейнтейнер или член @python и занимается
исправлениями при смене версии python 3.

Я целью вижу снижение количества геморроя при таких громких
обновлениях, а пересобрать сломавшийся пакет на порядки проще, чем
собирать одним заданием 870 пакетов.

-- 
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] python3.x(qwe) vs python3(qwe)

[Alexey Morozov]

В сообщении от Воскресенье 31 января 2010 18:24:34 автор Евгений Ростовцев 
написал:
> Привет!
> 
> > ЕР> В ходе многочисленных обсуждений я так и не понял, чем хороши
> > ЕР> провайдинги python3.x(qwe) и чем плохи python3(qwe).
> >
> > Это зависит от того будет ли у python3 точно также как и 2 ломаться
> > совместимость между minor версиями.
> 
> В том-то и вопрос состоит: с python 2.6 вышла фигня, что пришлось
> собирать пакеты одним громадным заданием.
Это два не вполне связанных события. Совместимость байт-кода между 2.5 и 2.6 
_вроде бы_ не ломалась. Однако _наша схема_ упаковки питона в любом случае 
предполагает революцию в репозитарии.

> А вот насчёт ломки совместимости: давайте подумаем, что за механизм может
> нам помочь такие разломы ловить индивидуально: при пересборке ли, репокопом
> ли. И индивидуально пусть мейнтейнер или член @python и занимается
> исправлениями при смене версии python 3.
Такие ломки можно отследить, отслеживая тенденции в мире питона. То есть, 
внимательно читать ченджлог каждой новой версии, тусуясь в сообществе 
разработчиков. И/Или создавая полноценный тестсьют для каждого из собираемых 
пакетов. 

> Я целью вижу снижение количества геморроя при таких громких
> обновлениях, а пересобрать сломавшийся пакет на порядки проще, чем
> собирать одним заданием 870 пакетов.
Тогда надо кардинально менять схему упаковки. В своём нынешнем виде и 
заявленных целях (кстати, если не секрет, есть где-нибудь место, где эти цели 
явно проартикулированны?) такая схема с необходимостью пучит весь репозиторий 
каждый раз, когда одна версия питона сменяется другой, которая так или иначе 
несовместима или может быть несовместима со старой.

С уважением,
Алексей Морозов

Re: [devel] python3.x(qwe) vs python3(qwe)

[Ivan A. Melnikov]

В Sun, 31 Jan 2010 14:50:01 +0400
"Sergey Y. Afonin" <asy@altlinux.ru> пишет:

> On Sunday 31 January 2010, Денис Смирнов wrote:
> 
> > ЕР> В ходе многочисленных обсуждений я так и не понял, чем хороши
> > ЕР> провайдинги python3.x(qwe) и чем плохи python3(qwe).
> > 
> > Это зависит от того будет ли у python3 точно также как и 2 ломаться
> > совместимость между minor версиями.
> 
> Вряд ли кто это узнает, пока оно не произойдёт... 
> 

Думаю, можно принять python3(qwe) и переползти на python3.x(qwe) когда
оно произойдёт. Гвидо где-то писал, что теперь хотел бы
стабильности языка, можно наверное проявить оптимизм.

-- 
WBR,
Ivan A. Melnikov

linux, c++, argentine tango -- in no particular order

Re: [devel] python3.x(qwe) vs python3(qwe)

[Sergei Epiphanov]

В сообщении от 1 февраля 2010 12:24:56 автор Ivan A. Melnikov написал:
> > Вряд ли кто это узнает, пока оно не произойдёт... 
> > 
> 
> Думаю, можно принять python3(qwe) и переползти на python3.x(qwe) когда
> оно произойдёт. Гвидо где-то писал, что теперь хотел бы
> стабильности языка, можно наверное проявить оптимизм.
> 
Насколько мне известно, уже есть 3.0 и 3.1. На них и попробовать.
-- 
С уважением, Епифанов Сергей

Re: [devel] python3.x(qwe) vs python3(qwe)

[Евгений Ростовцев]

Привет!

>> В том-то и вопрос состоит: с python 2.6 вышла фигня, что пришлось
>> собирать пакеты одним громадным заданием.
> Это два не вполне связанных события. Совместимость байт-кода между 2.5 и 2.6
> _вроде бы_ не ломалась. Однако _наша схема_ упаковки питона в любом случае
> предполагает революцию в репозитарии.

Революцию в питоне 2.* от меня не ждите, а вот насчёт python 3 - это
уже другая программа передач.

>> ли. И индивидуально пусть мейнтейнер или член @python и занимается
>> исправлениями при смене версии python 3.
> Такие ломки можно отследить, отслеживая тенденции в мире питона.

Да, я был на сайтах, посвящённых (хотя бы отчасти) питону 3,
мониторить, если есть рассылка - и можно будет надеяться на хотя бы
относительную (в сизифе, хехе) стабильность в этой области.

> внимательно читать ченджлог каждой новой версии, тусуясь в сообществе
> разработчиков. И/Или создавая полноценный тестсьют для каждого из собираемых
> пакетов.

Большинство встречавшихся мне питоньих пакетов имели средства
самотестирования. Другой вопрос, что не все они способны работать
внутри хэшера.

>> Я целью вижу снижение количества геморроя при таких громких
>> обновлениях, а пересобрать сломавшийся пакет на порядки проще, чем
>> собирать одним заданием 870 пакетов.
> Тогда надо кардинально менять схему упаковки.

Надо. Я к этому и клоню. Ну а раз пока про питон 3 в сизифе даже в
планах ни у кого не было, возьмусь за дело я. Как
программисту-архитектору мне это будет сделать легче, чем как
программисту-проектировщику.

> В своём нынешнем виде и
> заявленных целях (кстати, если не секрет, есть где-нибудь место, где эти
> цели
> явно проартикулированны?)

Не знаю. С моей стороны цель заявлена как "долой геморрой для
сообщества и пользователей".

> такая схема с необходимостью пучит весь
> репозиторий
> каждый раз, когда одна версия питона сменяется другой

Не уверен насчёт постоянного вспучивания (к тому же я уже говорил, что
с питоном 2 я этого больше не буду делать - другие, кто этим
занимался, меня поддержат).

А вот с питоном 3 я с самого начала решил закладываться на
относительную безболезненность поднятия версии (не до 4, нет :-D ). У
нас в любом случае геморрой с питоном бывает периодически (как только
поднялась версия у NumPy, так сразу требуется пересобрать ряд пакетов,
причём, предсказать, каких именно - способа не знаю, узнаю только на
своём опыте или по жалобам в багзилле). И я почему-то вовсе не уверен,
что новая схема (с питоном 3) увеличит количество геморроя. Снизить -
вполне может, но это гадание на кофейной гуще.

-- 
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] python3.x(qwe) vs python3(qwe)

[Andrey Rahmatullin]

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

On Mon, Feb 01, 2010 at 12:03:14AM +0600, Alexey Morozov wrote:
> Тогда надо кардинально менять схему упаковки. В своём нынешнем виде и 
> заявленных целях (кстати, если не секрет, есть где-нибудь место, где эти цели 
> явно проартикулированны?)
Только не говори, что ты не имеешь отношения к нашему Python Policy.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<gns> # grep ^'[^#]' httpd2.conf | grep Include
      Include conf/ports-enabled/*.conf
      Include conf/mods-enabled/*.load
      Include conf/mods-enabled/*.conf
<gns> против знатоков играет телезритель Aleksey Avdeev <solo@altlinux.ru>.
      Внимание вопрос: будет ли апач с таким httpd.conf слушать порт 443, если
      в ports-enabled/https.conf написано  <IfModule ssl_module> Listen 443
      </IfModule> ?
<gns> ... правильно! ещё один телезритель выиграл два часа моего времени!

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Ivan Fedorov]

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

Alexey Morozov <morozov-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:

> В сообщении от Воскресенье 31 января 2010 18:24:34 автор Евгений Ростовцев 
> написал:
>> Привет!
>> 
>> > ЕР> В ходе многочисленных обсуждений я так и не понял, чем хороши
>> > ЕР> провайдинги python3.x(qwe) и чем плохи python3(qwe).
>> >
>> > Это зависит от того будет ли у python3 точно также как и 2 ломаться
>> > совместимость между minor версиями.
>> 
>> В том-то и вопрос состоит: с python 2.6 вышла фигня, что пришлось
>> собирать пакеты одним громадным заданием.
> Это два не вполне связанных события. Совместимость байт-кода между 2.5 и 2.6 
> _вроде бы_ не ломалась.
не знаю, не знаю, но magic bytes сменились!

>> Я целью вижу снижение количества геморроя при таких громких
>> обновлениях, а пересобрать сломавшийся пакет на порядки проще, чем
>> собирать одним заданием 870 пакетов.
> Тогда надо кардинально менять схему упаковки. В своём нынешнем виде и 
> заявленных целях (кстати, если не секрет, есть где-нибудь место, где эти цели 
> явно проартикулированны?) такая схема с необходимостью пучит весь репозиторий 
> каждый раз, когда одна версия питона сменяется другой, которая так или иначе 
> несовместима или может быть несовместима со старой.
на мой взгляд тут единственный вариант, это компилить pyc-файлы уже
после установки пакета. каким-нить posttrigger.

Но объём работы тут IMHО ещё более ужасен, чем пересборка 1000
пакетов. А с arch-пакетами всё равно не поможет - они зависят от
полноценной линковки с libpython.

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Andrey Rahmatullin]

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

On Tue, Feb 02, 2010 at 12:45:43PM +0300, Ivan Fedorov wrote:
> на мой взгляд тут единственный вариант, это компилить pyc-файлы уже
> после установки пакета. каким-нить posttrigger.
... и по кругу.


http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-byte_compilation


-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

> Так все-таки, какой табак кто порекомендует для забивки в гильзы ? ;-)
glibc(1) на бумаге 80 г/м2? ;-)
		-- mike in smoke-room@

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Alexey Morozov]

В сообщении от Вторник 02 февраля 2010 12:06:56 автор Andrey Rahmatullin 
написал:
> On Mon, Feb 01, 2010 at 12:03:14AM +0600, Alexey Morozov wrote:
> > Тогда надо кардинально менять схему упаковки. В своём нынешнем виде и
> > заявленных целях (кстати, если не секрет, есть где-нибудь место, где эти
> > цели явно проартикулированны?)
> 
> Только не говори, что ты не имеешь отношения к нашему Python Policy.

Оно прокисло и как минимум в одном важном пункте не соблюдается. Так что, 
можно считать его практически несущественным, хотя, _возможно_ , и интересным 
с исторической точки зрения.

На мой взгляд, основная проблема нынешней схемы:

с одной стороны, используются механизмы привязывания модуля к определённой 
версии при сборке пакета (собственно, для большинства модулей эти механизмы 
вытекают из схемы их расположения, %_libdir/pythonX.Y, а для меньшей части - 
из привязок к libpython). При этом, замечу, основная цель выбранного 
расположения, - борьба с несовместимостями между версиями и архитектурами в 
питоньем байткоде, - выглядит для меня достаточно умозрительной here and now.

с другой стороны, заложенную при написании питон-полиси схему с множественным 
питоном и плавной, итеративной миграцией модулей, благополучно пристрелили. В 
общем, она и вправду, видимо, того стоила, но, факт, необходимость 
множественности питонов напрямую следует из сформулированных _тогда_ целей.

Как из этого выходить? Фиг знает. Можно, например, отказаться от принципа 
"инсталлируется apt'ом - значит работоспособно" (да-да, я знаю, что это плохо 
:) ). 

Кстати, вероятнее всего, 90-ста процентам тех пакетов, которые используют 
питон в качестве языка скриптования, совсем необязателен "полноценный питон" 
со сколько-нибудь полной библиотекой, достаточно libpython. Соответственно, 
масштаб революции в репозитории можно будет сильно уменьшить, если в момент 
заливки нового питона предоставлять libpython-compat для уходящей версии.

Второй вариант - научиться автоматически блокировать в репозитории пакеты, 
которые явно или неявно связаны с питоном, чтобы заливка новой версии не 
превращалась в увлекательную игру с Ахиллесом и черепахой в главных ролях. Но 
тут, чес-гря, я не знаю, каковы будут трудозатраты на реализацию такого 
решения.

Дебиановцы, повторюсь, пошли по третьему пути. source-level пакеты 
распространяются в виде .py, которые при инсталляции раскладываются вместе со 
сгенерёнными тут же .pyc в каталоги, соответствующие установленным на 
конкретной машине версиям python'а. Отдельно решается вопрос с архитектурно-
зависимыми, "бинарными" пакетами.

Насколько я понимаю, на сегодняшний день у них наиболее чётко проработана 
схема с поддержкой нескольких версий питона одновременно, и эта схема как 
никакая другая рассчитана на независимую, "распределённую" процедуру 
обновления пакетов в репозитории. В том числе, и обновлении питона и его 
запчастей.

Ну, в общем, как-то так. Собственно, когда я спрашивал о явном проговаривании 
целей, я подразумевал, что такое проговаривание позволит понять, какие решения 
являются абсолютно необходимыми, а от каких можно и нужно безболезненно 
отказаться.

АМ

Re: [devel] python3.x(qwe) vs python3(qwe)

[Alexey Morozov]

В сообщении от Вторник 02 февраля 2010 15:45:43 автор Ivan Fedorov написал:
> не знаю, не знаю, но magic bytes сменились!
> 
Ну, значит, схалявить не получится. Это, кстати, ответ на вопрос Евгения, 
вынесенный в тему письма: правильно ставить python3.x(qwe).

АМ

Re: [devel] python3.x(qwe) vs python3(qwe)

[Alexey Morozov]

В сообщении от Вторник 02 февраля 2010 16:54:18 автор Alexey Morozov написал:
>  При этом, замечу, основная цель выбранного
>  расположения, - борьба с несовместимостями между версиями и архитектурами
>  в питоньем байткоде, - выглядит для меня достаточно умозрительной here and
>  now.
Иван поправил насчёт умозрительности, так что, деваться некуда, надо .pyc'и 
разносить. Или забить на то, что на то, что при смене питона собранные 
ранее.pyc/.pyo прокисают и использоваться не будут.

Re: [devel] python3.x(qwe) vs python3(qwe)

[Andrey Rahmatullin]

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

On Tue, Feb 02, 2010 at 04:54:18PM +0600, Alexey Morozov wrote:
> > > Тогда надо кардинально менять схему упаковки. В своём нынешнем виде и
> > > заявленных целях (кстати, если не секрет, есть где-нибудь место, где эти
> > > цели явно проартикулированны?)
> > Только не говори, что ты не имеешь отношения к нашему Python Policy.
> Оно прокисло и как минимум в одном важном пункте не соблюдается. Так что, 
> можно считать его практически несущественным, хотя, _возможно_ , и интересным 
> с исторической точки зрения.
Но спрашиваешь-то ты его обоснование.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<hiddenman> gns: а чего ты в винде сидишь? enterprise linux не работает на
            ноуте? :)
<gns> hiddenman: венда то на десктопе брат юзает
<raorn> пошли отмазки
<raorn> брат, жена, мать
<raorn> все вы латентные вендовозники

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Andrey Rahmatullin]

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

On Tue, Feb 02, 2010 at 04:54:18PM +0600, Alexey Morozov wrote:
> Насколько я понимаю, на сегодняшний день у них наиболее чётко проработана 
> схема с поддержкой нескольких версий питона одновременно, и эта схема как 
> никакая другая рассчитана на независимую, "распределённую" процедуру 
> обновления пакетов в репозитории. В том числе, и обновлении питона и его 
> запчастей.
Не стоит тратить своё и чужое время на повторение известных и уже не раз
высказанных фактов, это ничего не изменит.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

Призрак бродит по сизифу ;), ты не чувствуешь его скользкий и
холодный хвост?
		-- cray in devel@

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Dmitry V. Levin]

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

On Tue, Feb 02, 2010 at 03:07:46PM +0500, Andrey Rahmatullin wrote:
> On Tue, Feb 02, 2010 at 12:45:43PM +0300, Ivan Fedorov wrote:
> > на мой взгляд тут единственный вариант, это компилить pyc-файлы уже
> > после установки пакета. каким-нить posttrigger.
> ... и по кругу.
> 
> http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-byte_compilation

Применительно к нашим условиям:
- автоматически добавлять %ghost %verify(not size md5 mtime) к pyc- и
  pyo-файлам относительно несложно;
- реализовать post-transaction filetrigger, который будет воссоздавать
  эти файлы, тоже относительно несложно;
- бинарных пакетов, слинкованных с libpython2.6.so.1.0, сейчас в Сизифе
  322 штуки (не считая python-modules-*), и от "binary NMUs" при каждой
  смене "default Python version" всё равно, видимо, никуда не деться.

Вот из-за этих 322 пакетов, которые слинкованы с "default Python version",
и не получается более одного полноценного питона в репозитории.


-- 
ldv

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Dmitry V. Levin]

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

On Tue, Feb 02, 2010 at 05:19:10PM +0500, Andrey Rahmatullin wrote:
> On Tue, Feb 02, 2010 at 04:54:18PM +0600, Alexey Morozov wrote:
> > Насколько я понимаю, на сегодняшний день у них наиболее чётко проработана 
> > схема с поддержкой нескольких версий питона одновременно, и эта схема как 
> > никакая другая рассчитана на независимую, "распределённую" процедуру 
> > обновления пакетов в репозитории. В том числе, и обновлении питона и его 
> > запчастей.
> Не стоит тратить своё и чужое время на повторение известных и уже не раз
> высказанных фактов, это ничего не изменит.

Вопрос, прописанное в правилах единовременное binary NMU на несколько
сотен пакетов -- это и есть та самая знаменитая схема (независимая,
распределённая, и всё такое)?  Или та схема устроена совершенно иначе?


-- 
ldv

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Alexey Morozov]

В сообщении от Вторник 02 февраля 2010 18:19:10 автор Andrey Rahmatullin 
написал:
> On Tue, Feb 02, 2010 at 04:54:18PM +0600, Alexey Morozov wrote:
> > Насколько я понимаю, на сегодняшний день у них наиболее чётко проработана
> > схема с поддержкой нескольких версий питона одновременно, и эта схема как
> > никакая другая рассчитана на независимую, "распределённую" процедуру
> > обновления пакетов в репозитории. В том числе, и обновлении питона и его
> > запчастей.
> 
> Не стоит тратить своё и чужое время на повторение известных и уже не раз
> высказанных фактов, это ничего не изменит.

Андрей, у меня ощущение, что Евгений не в курсе этих "очевидных" фактов. Так 
что, можешь считать, данный абзац адресовался не тебе.

Кстати, Андрей Орлов как-то говорил, что в момент формулирования целей и задач 
нашего питон-полиси о существовании дебиановского он не знал. Может быть, 
когда/если Евгений возьмётся формулировать более-менее строго ту задачу, 
которую он описывает как  "долой геморрой для сообщества и пользователей", 
информация о том, что кто-то уже побегал по этим граблям и нащупал дорожку, 
ему пригодится.

АМ

P.S. Евгений, простите, что мы о Вас тут в третьем лице, это не нарочно.

Re: [devel] python3.x(qwe) vs python3(qwe)

[Andrey Rahmatullin]

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

On Tue, Feb 02, 2010 at 06:31:29PM +0600, Alexey Morozov wrote:
> Андрей, у меня ощущение, что Евгений не в курсе этих "очевидных" фактов.
Предложения "посмотреть как в Debian" высказываются здесь регулярно.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<AMorozov> Что один человек сделал, другой завсегда сломать сможет...
<AMorozov> В особенности, если этот другой - я :-)

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Andrey Rahmatullin]

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

On Tue, Feb 02, 2010 at 03:23:40PM +0300, Dmitry V. Levin wrote:
> > > Насколько я понимаю, на сегодняшний день у них наиболее чётко проработана 
> > > схема с поддержкой нескольких версий питона одновременно, и эта схема как 
> > > никакая другая рассчитана на независимую, "распределённую" процедуру 
> > > обновления пакетов в репозитории. В том числе, и обновлении питона и его 
> > > запчастей.
> > Не стоит тратить своё и чужое время на повторение известных и уже не раз
> > высказанных фактов, это ничего не изменит.
> Вопрос, прописанное в правилах единовременное binary NMU на несколько
> сотен пакетов -- это и есть та самая знаменитая схема (независимая,
> распределённая, и всё такое)?  Или та схема устроена совершенно иначе?
http://www.mail-archive.com/debian-python@lists.debian.org/msg06228.html

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

По вопросам работы pkg-build-priv пишите мне.
На все остальные вопросы по этой теме с радостью ответит avn@. :)
		-- ldv in devel@

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Alexey Morozov]

В сообщении от Вторник 02 февраля 2010 18:19:15 автор Dmitry V. Levin написал:
> Применительно к нашим условиям:
> - автоматически добавлять %ghost %verify(not size md5 mtime) к pyc- и
>   pyo-файлам относительно несложно;
> - реализовать post-transaction filetrigger, который будет воссоздавать
>   эти файлы, тоже относительно несложно;
> - бинарных пакетов, слинкованных с libpython2.6.so.1.0, сейчас в Сизифе
>   322 штуки (не считая python-modules-*), и от "binary NMUs" при каждой
>   смене "default Python version" всё равно, видимо, никуда не деться.
> 
> Вот из-за этих 322 пакетов, которые слинкованы с "default Python version",
> и не получается более одного полноценного питона в репозитории.

А зачем нужно принудительно переводить всех на default Python version? В 
дебиановском репозитории (Lenny) совершенно спокойно соседствуют те, кому 
нужен python2.4, и те, кто завязан на python2.5. Могу списочки приложить, но 
они длинные (62 rdepend на 2.4 и 141 - на 2.5)

В этой схеме есть только один недостаток - неработающий rpm --verify. Точнее, 
работающий, но сравнительно бесполезный, т.к. самое интересное - за пределами 
его видимости.

Re: [devel] python3.x(qwe) vs python3(qwe)

[Dmitry V. Levin]

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

On Tue, Feb 02, 2010 at 06:42:56PM +0600, Alexey Morozov wrote:
> В сообщении от Вторник 02 февраля 2010 18:19:15 автор Dmitry V. Levin написал:
> > Применительно к нашим условиям:
> > - автоматически добавлять %ghost %verify(not size md5 mtime) к pyc- и
> >   pyo-файлам относительно несложно;
> > - реализовать post-transaction filetrigger, который будет воссоздавать
> >   эти файлы, тоже относительно несложно;
> > - бинарных пакетов, слинкованных с libpython2.6.so.1.0, сейчас в Сизифе
> >   322 штуки (не считая python-modules-*), и от "binary NMUs" при каждой
> >   смене "default Python version" всё равно, видимо, никуда не деться.
> > 
> > Вот из-за этих 322 пакетов, которые слинкованы с "default Python version",
> > и не получается более одного полноценного питона в репозитории.
> 
> А зачем нужно принудительно переводить всех на default Python version? В 
> дебиановском репозитории (Lenny) совершенно спокойно соседствуют те, кому 
> нужен python2.4, и те, кто завязан на python2.5. Могу списочки приложить, но 
> они длинные (62 rdepend на 2.4 и 141 - на 2.5)

А как же это работает, когда приложению нужно 2 модуля, которые слинкованы
с разными версиями python?


-- 
ldv

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Andrey Rahmatullin]

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

On Tue, Feb 02, 2010 at 05:23:39PM +0300, Dmitry V. Levin wrote:
> А как же это работает, когда приложению нужно 2 модуля, которые слинкованы
> с разными версиями python?
Они не линкуются с libpython.
Some distributions link extensions to libpython, but this is not the case
in Debian as symbols might as well be resolved by /usr/bin/pythonX.Y which
is not linked to libpython.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

>ps: куплю билеты на матч ldv--rider, т.к. пока изложенные ими
>позиции существенно противоречат друг другу ;[
Организуем на linuxfest. Билеты в танцевальный партер -- $50.
		-- aen in devel-kernel@

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Dmitry V. Levin]

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

On Tue, Feb 02, 2010 at 07:33:04PM +0500, Andrey Rahmatullin wrote:
> On Tue, Feb 02, 2010 at 05:23:39PM +0300, Dmitry V. Levin wrote:
> > А как же это работает, когда приложению нужно 2 модуля, которые слинкованы
> > с разными версиями python?
> Они не линкуются с libpython.

А чем тогда гарантируется совместимость модуля с питоном, под который он
был собран?


-- 
ldv

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Michael Shigorin]

On Sun, Jan 31, 2010 at 12:33:29PM +0300, Денис Смирнов wrote:
> ЕР> В ходе многочисленных обсуждений я так и не понял, чем хороши
> ЕР> провайдинги python3.x(qwe) и чем плохи python3(qwe).
> Это зависит от того будет ли у python3 точно также как и 2 ломаться
> совместимость между minor версиями.

Причём исходить лучше из худшего (что ломаться будет),
чем потом аврально решать проблему.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] python3.x(qwe) vs python3(qwe)

[Dmitry V. Levin]

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

On Tue, Feb 02, 2010 at 05:39:51PM +0300, Dmitry V. Levin wrote:
> On Tue, Feb 02, 2010 at 07:33:04PM +0500, Andrey Rahmatullin wrote:
> > On Tue, Feb 02, 2010 at 05:23:39PM +0300, Dmitry V. Levin wrote:
> > > On Tue, Feb 02, 2010 at 06:42:56PM +0600, Alexey Morozov wrote:
> > > > В сообщении от Вторник 02 февраля 2010 18:19:15 автор Dmitry V. Levin написал:
> > > > > Применительно к нашим условиям:
> > > > > - автоматически добавлять %ghost %verify(not size md5 mtime) к pyc- и
> > > > >   pyo-файлам относительно несложно;
> > > > > - реализовать post-transaction filetrigger, который будет воссоздавать
> > > > >   эти файлы, тоже относительно несложно;
> > > > > - бинарных пакетов, слинкованных с libpython2.6.so.1.0, сейчас в Сизифе
> > > > >   322 штуки (не считая python-modules-*), и от "binary NMUs" при каждой
> > > > >   смене "default Python version" всё равно, видимо, никуда не деться.
> > > > > 
> > > > > Вот из-за этих 322 пакетов, которые слинкованы с "default Python version",
> > > > > и не получается более одного полноценного питона в репозитории.
> > > > 
> > > > А зачем нужно принудительно переводить всех на default Python version? В 
> > > > дебиановском репозитории (Lenny) совершенно спокойно соседствуют те, кому 
> > > > нужен python2.4, и те, кто завязан на python2.5. Могу списочки приложить, но 
> > > > они длинные (62 rdepend на 2.4 и 141 - на 2.5)
> > > 
> > > А как же это работает, когда приложению нужно 2 модуля, которые слинкованы
> > > с разными версиями python?
> > > 
> > Они не линкуются с libpython.
> 
> А чем тогда гарантируется совместимость модуля с питоном, под который он
> был собран?

Видимо, вопрос оказался слишком сложным, попробую переформулировать.

Eсли не все extension modules переводятся на default version единовременно,
то как быть с теми пакетами, которым нужно два разных extension modules,
собранных под разные питоны?  Какой механизм выявляет всех таких
клиентов в репозитории, чем этот механизм принципиально отличается от
нашего механизма зависимостей вида pythonN.M(module)?


-- 
ldv

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Dmitry V. Levin]

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

On Fri, Feb 05, 2010 at 03:33:03AM +0300, Dmitry V. Levin wrote:
> On Tue, Feb 02, 2010 at 05:39:51PM +0300, Dmitry V. Levin wrote:
> > On Tue, Feb 02, 2010 at 07:33:04PM +0500, Andrey Rahmatullin wrote:
> > > On Tue, Feb 02, 2010 at 05:23:39PM +0300, Dmitry V. Levin wrote:
> > > > On Tue, Feb 02, 2010 at 06:42:56PM +0600, Alexey Morozov wrote:
> > > > > В сообщении от Вторник 02 февраля 2010 18:19:15 автор Dmitry V. Levin написал:
[...]
> > > > > > Вот из-за этих 322 пакетов, которые слинкованы с "default Python version",
> > > > > > и не получается более одного полноценного питона в репозитории.
> > > > > 
> > > > > А зачем нужно принудительно переводить всех на default Python version? В 
> > > > > дебиановском репозитории (Lenny) совершенно спокойно соседствуют те, кому 
> > > > > нужен python2.4, и те, кто завязан на python2.5. Могу списочки приложить, но 
> > > > > они длинные (62 rdepend на 2.4 и 141 - на 2.5)
> > > > 
> > > > А как же это работает, когда приложению нужно 2 модуля, которые слинкованы
> > > > с разными версиями python?
> > > > 
> > > Они не линкуются с libpython.
> > 
> > А чем тогда гарантируется совместимость модуля с питоном, под который он
> > был собран?
> 
> Видимо, вопрос оказался слишком сложным, попробую переформулировать.
> 
> Eсли не все extension modules переводятся на default version единовременно,
> то как быть с теми пакетами, которым нужно два разных extension modules,
> собранных под разные питоны?  Какой механизм выявляет всех таких
> клиентов в репозитории, чем этот механизм принципиально отличается от
> нашего механизма зависимостей вида pythonN.M(module)?

Если изложенное в
http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-version_indep_progs
http://www.debian.org/doc/packaging-manuals/python-policy/ap-upgrade.html
соответствует действительности, то процедура обновления default Python
version в Unstable занимает заметное время, в течение которого многие
пакеты могут оказаться в описанном выше положении "между двумя питонами".


-- 
ldv

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

Re: [devel] python3.x(qwe) vs python3(qwe)

[Евгений Ростовцев]

>> Хедер там с релиза 1.1 минимум, видать, чел давно не
>> обновлялся. Так что ничего _Я_ не перекладывал.
>
> Жень, а ты точно sure?
>
> $ for i in python-module-pygtk-devel-2.17.0-alt*; do rpm -qp
> --qf='%{RELEASE} (%{BUILDHOST}):\t' $i; rpm -qlp $i | fgrep pygtk.h; done
> alt1.1 (real-sisyphus.hasher.altlinux.org):
> /usr/include/python2.6/pygtk/pygtk/pygtk.h
> alt1 (aris-sisyphus.hasher.altlinux.org):
> /usr/include/python2.6/pygtk/pygtk/pygtk.h
> alt2.1 (real-sisyphus.hasher.altlinux.org):
> /usr/include/python2.6/pygtk/pygtk/pygtk/pygtk.h
> alt2 (aris-sisyphus.hasher.altlinux.org):
> /usr/include/python2.6/pygtk/pygtk/pygtk.h
> alt3 (aris-sisyphus.hasher.altlinux.org):
> /usr/include/python2.6/pygtk/pygtk/pygtk.h

Ну здесь же хорошо видно, что винить нужно всё же меня, но тогда от
меня ускольнула суть той баги (там, если я не забыл, удивлялись, что
нет хедера /usr/include/python2.6/pygtk/pygtk/pygtk/pygtk.h). Здесь
видна аргументация, в отличие от закидывания ссылок, что в случае
сборки из srpm равносильно вообще отсутствию аргументации.

Так что прошу прощения у team за долгие препирательства. Был неправ.

PS. Но это не отменяет намерения форкнуть PyGTK: так и мне будет
спокойней (сам накосячил - сам наладил), и не будет возмущений
_лидеров_ на случайно ошибочные манипуляции с их пакетами.

-- 
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] python3.x(qwe) vs python3(qwe)

[Andrey Rahmatullin]

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

On Fri, Feb 05, 2010 at 01:58:26PM +0700, Евгений Ростовцев wrote:
> Ну здесь же хорошо видно, что винить нужно всё же меня, но тогда от
> меня ускольнула суть той баги (там, если я не забыл, удивлялись, что
> нет хедера /usr/include/python2.6/pygtk/pygtk/pygtk/pygtk.h). 

"""
В /usr/lib/pkgconfig/pygtk-2.0.pc указано что
pygtkincludedir=${includedir}/python2.6/pygtk

а на самом деле в /usr/include/python2.6/pygtk/pygtk/pygtk/pygtk.h
"""

> PS. Но это не отменяет намерения форкнуть PyGTK: так и мне будет
> спокойней (сам накосячил - сам наладил), и не будет возмущений
> _лидеров_ на случайно ошибочные манипуляции с их пакетами.
Форкайте сразу весь ALT.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

> НАРОД, ПОВЕСЬТЕ КИЛЯТОР БИТЫХ СМИЛИНКОВ НА FTP
Пришёл килятор и все битые симлинки закилял. :)
		-- ldv in sisyphus@

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

[devel] pygtk (was: python3.x(qwe) vs python3(qwe))

[Michael Shigorin]

On Fri, Feb 05, 2010 at 01:58:26PM +0700, Евгений Ростовцев wrote:
> >> Хедер там с релиза 1.1 минимум, видать, чел давно не
> >> обновлялся. Так что ничего _Я_ не перекладывал.
> > Жень, а ты точно sure?
> >
> > $ for i in python-module-pygtk-devel-2.17.0-alt*; do rpm -qp
> > --qf='%{RELEASE} (%{BUILDHOST}):\t' $i; rpm -qlp $i | fgrep pygtk.h; done
> > alt1.1 (real-sisyphus.hasher.altlinux.org):
> > /usr/include/python2.6/pygtk/pygtk/pygtk.h
> > alt1 (aris-sisyphus.hasher.altlinux.org):
> > /usr/include/python2.6/pygtk/pygtk/pygtk.h
> > alt2.1 (real-sisyphus.hasher.altlinux.org):
> > /usr/include/python2.6/pygtk/pygtk/pygtk/pygtk.h
> > alt2 (aris-sisyphus.hasher.altlinux.org):
> > /usr/include/python2.6/pygtk/pygtk/pygtk.h
> > alt3 (aris-sisyphus.hasher.altlinux.org):
> > /usr/include/python2.6/pygtk/pygtk/pygtk.h
> Ну здесь же хорошо видно, что винить нужно всё же меня, но тогда от
> меня ускольнула суть той баги (там, если я не забыл, удивлялись, что
> нет хедера /usr/include/python2.6/pygtk/pygtk/pygtk/pygtk.h).

Как раз наоборот -- удивлялись разъезду информации в pkgconfig
и положения под /usr/include:

--- 
пакет python-module-pygtk-devel-2.17.0-alt2.1

В /usr/lib/pkgconfig/pygtk-2.0.pc указано что
pygtkincludedir=${includedir}/python2.6/pygtk

а на самом деле в /usr/include/python2.6/pygtk/pygtk/pygtk/pygtk.h

Из-за этого pygtk.h не находится.
--- https://bugzilla.altlinux.org/22872

> Здесь видна аргументация, в отличие от закидывания ссылок,
> что в случае сборки из srpm равносильно вообще отсутствию
> аргументации.

Понимаешь, по коммитам тоже не всегда очевидно -- особенно
если ошибка настолько глупая, что проскакивает мимо глаз.
Поэтому в случаях, когда непонятки, завёл привычку проверять
_всё_ с самого-самого начала, не делая предположений.

Именно поэтому в http://www.altlinux.org/NMU и выписаны секции
"Технические требования к NMU" и "Дополнительная информация".
Предлагаю перечитать их и оценить уместность.

> Так что прошу прощения у team за долгие препирательства.
> Был неправ.

Бывает.  Хорошо, что хорошо кончается :)

> PS. Но это не отменяет намерения форкнуть PyGTK: так и мне
> будет спокойней (сам накосячил - сам наладил), и не будет
> возмущений _лидеров_ на случайно ошибочные манипуляции с их
> пакетами.

А мне с чем собираться тогда?  Нет уж, давайте как-нить учиться
потерпеть и глупые ошибки, и невнятные назидания друг друга.
Не со зла же.

2 aris: принято?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] python3.x(qwe) vs python3(qwe)

[Michael Shigorin]

On Fri, Feb 05, 2010 at 12:01:25PM +0500, Andrey Rahmatullin wrote:
> > PS. Но это не отменяет намерения форкнуть PyGTK: так и мне будет

Насколько понимаю, тебе нужна svn-версия?  Так это повод
_совместно_ обдумать, как без лишних спецэффектов собрать
её рядом, только и всего.

> > спокойней (сам накосячил - сам наладил), и не будет возмущений
> > _лидеров_ на случайно ошибочные манипуляции с их пакетами.
> Форкайте сразу весь ALT.

Беда в том, что с почему-то ставшим привычным высокомерием
это действительно приходит на ум, но тогда проще сваливать
уж на Debian.

Потому и -- давайте всё ж объяснять внятно, а не предполагать,
что коллега намеренно всё испортил (и точно знает, что именно).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] python3.x(qwe) vs python3(qwe)

[Dmitry V. Levin]

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

On Fri, Feb 05, 2010 at 03:54:43AM +0300, Dmitry V. Levin wrote:
> On Fri, Feb 05, 2010 at 03:33:03AM +0300, Dmitry V. Levin wrote:
[...]
> > Eсли не все extension modules переводятся на default version единовременно,
> > то как быть с теми пакетами, которым нужно два разных extension modules,
> > собранных под разные питоны?  Какой механизм выявляет всех таких
> > клиентов в репозитории, чем этот механизм принципиально отличается от
> > нашего механизма зависимостей вида pythonN.M(module)?
> 
> Если изложенное в
> http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-version_indep_progs
> http://www.debian.org/doc/packaging-manuals/python-policy/ap-upgrade.html
> соответствует действительности, то процедура обновления default Python
> version в Unstable занимает заметное время, в течение которого многие
> пакеты могут оказаться в описанном выше положении "между двумя питонами".

Аналогичная ситуация складывается при смене soname у библиотек: до тех
пор, пока не все пакеты пересобраны с новым soname, некоторые пакеты
могут оказаться в положении "между двумя soname", при котором в памяти
приложения оказывается сразу старая и новая версия библиотеки.

Традиционно принято считать, что вероятность таких событий невелика, и,
стало быть, можно реагировать на них по мере поступления сообщений об
ошибках.


-- 
ldv

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