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

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

[Andrey Orlov]

Hi!

Мы переходим на python 2.4.0., который Гвидо почему-то решил назвать 2.4, чем подложил мне немножко граблей.
В инкоминг сизифа залиты пакеты python-2.4.0-alt5 (собственно новая версия) и python2.3-2.3.4-alt7  (бывший python).
Всем мантейнерам пакетов python рекомендуется сделать следующее:

 apt-get dist-upgrade

 python

 убедится, что питон вообще запускается и в том, что это версия 2.4.

 Пересобрать свой пакет в хешере

 (*) убедится что он работает

 Залить его в сизиф
 
Работа как вы понимаете ручная, потому как п. (*) автоматизации не поддается. Тем не менее, мне было бы интересно
обсудить с тем, кто за это отвечает, возможность устроить автоматическую пересборку, свяжитесь со мной, по возможности
через жаббер - ну или как удобно.

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

По поводу остальных наших пакетов (в т.ч. Zope) - появятся, как только пересобранные питоны будут в репозитории.

И. наконец, небольшие грабли для инкомингера: там валяется пара сборок python-2.4- (не 2.4.0!) вот они не работают,
залиты не то что бы по ошибке, просто я поздно заметил сначала одни грабли, а потом другие.

PS: Давно не понимаю, кто мантейнит omniORB. Поскольку я ее оч. люблю, то я ее пересобрал. Новую версию. Работает. 
Как только - так залью. Вмести с omniEvents & omniNotify.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Dmitry V. Levin]

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

Hi,

On Wed, Mar 09, 2005 at 10:49:09AM +0300, Andrey Orlov wrote:
> Мы переходим на python 2.4.0., который Гвидо почему-то решил назвать 2.4, чем подложил мне немножко граблей.
> В инкоминг сизифа залиты пакеты python-2.4.0-alt5 (собственно новая версия) и python2.3-2.3.4-alt7  (бывший python).
> Всем мантейнерам пакетов python рекомендуется сделать следующее:
> 
>  apt-get dist-upgrade
> 
>  python
> 
>  убедится, что питон вообще запускается и в том, что это версия 2.4.
> 
>  Пересобрать свой пакет в хешере
> 
>  (*) убедится что он работает
> 
>  Залить его в сизиф
>  
> Работа как вы понимаете ручная, потому как п. (*) автоматизации не поддается. Тем не менее, мне было бы интересно
> обсудить с тем, кто за это отвечает, возможность устроить автоматическую пересборку, свяжитесь со мной, по возможности
> через жаббер - ну или как удобно.

В принципе это возможно, об этом надо договориться с incoming@.

Технически это несколько сложнее обычного, поскольку у большинства
исходных пакетов есть сборочная зависимость на "python-devel = 2.3".
Впрочем, для этого есть "hsh --query-req-prog".


-- 
ldv

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

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

[Alexey Morozov]

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

On Fri, Mar 11, 2005 at 06:43:21PM +0300, Dmitry V. Levin wrote:
> Технически это несколько сложнее обычного, поскольку у большинства
> исходных пакетов есть сборочная зависимость на "python-devel = 2.3".
Зависимость эта насчитывается автоматически и в спеке (в Правильном
Спеке) не фигурирует. Так что, в большинстве случаев достаточно
сделать, грубо говоря,

rpm -i python-module-Somemodule-1.2.3-alt4.src.rpm
rpm -ba python-module-Somemodule.spec

или даже

rpm --rebuild python-module-Somemodule-1.2.3-alt4.src.rpm

в системе, где установлен "правильный" питон.
Или я неправильно понял трудности?


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

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

[Dmitry V. Levin]

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

On Fri, Mar 11, 2005 at 10:08:47PM +0600, Alexey Morozov wrote:
> On Fri, Mar 11, 2005 at 06:43:21PM +0300, Dmitry V. Levin wrote:
> > Технически это несколько сложнее обычного, поскольку у большинства
> > исходных пакетов есть сборочная зависимость на "python-devel = 2.3".
> Зависимость эта насчитывается автоматически и в спеке (в Правильном
> Спеке) не фигурирует. Так что, в большинстве случаев достаточно
> сделать, грубо говоря,
> 
> rpm -i python-module-Somemodule-1.2.3-alt4.src.rpm
> rpm -ba python-module-Somemodule.spec
> 
> или даже
> 
> rpm --rebuild python-module-Somemodule-1.2.3-alt4.src.rpm
> 
> в системе, где установлен "правильный" питон.
> Или я неправильно понял трудности?

Я бы сказал, не совсем правильно.

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


-- 
ldv

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

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

[Mikhail Zabaluev]

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

В Птн, 11/03/2005 в 22:08 +0600, Alexey Morozov пишет:
> > Технически это несколько сложнее обычного, поскольку у большинства
> > исходных пакетов есть сборочная зависимость на "python-devel = 2.3".
> Зависимость эта насчитывается автоматически и в спеке (в Правильном
> Спеке) не фигурирует. Так что, в большинстве случаев достаточно
> сделать, грубо говоря,
> 
> rpm -i python-module-Somemodule-1.2.3-alt4.src.rpm
> rpm -ba python-module-Somemodule.spec
> 
> или даже
> 
> rpm --rebuild python-module-Somemodule-1.2.3-alt4.src.rpm

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Alexey Morozov]

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

On Sun, Mar 13, 2005 at 09:37:47PM +0300, Mikhail Zabaluev wrote:
> > rpm --rebuild python-module-Somemodule-1.2.3-alt4.src.rpm
> Я ранее уже говорил, что делать _исходный_ пакет зависимым от среды
> сборки -- порочная практика.
Ну, возможно, следует ограничить привязку
python-devel'ом, а версию этуму python-devel'у проставлять только
в случае "явной привязки", т.е. --with pythonXY.


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

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

[Andrey Orlov]

On Monday 14 March 2005 11:46, Alexey Morozov wrote:
> On Sun, Mar 13, 2005 at 09:37:47PM +0300, Mikhail Zabaluev wrote:
> > > rpm --rebuild python-module-Somemodule-1.2.3-alt4.src.rpm
> > Я ранее уже говорил, что делать _исходный_ пакет зависимым от среды
> > сборки -- порочная практика.
> Ну, возможно, следует ограничить привязку
> python-devel'ом, а версию этуму python-devel'у проставлять только
> в случае "явной привязки", т.е. --with pythonXY.

Это уже обсуждалось неоднократно. Если мы хотим иметь набор питоновских пакетов, которые
работают или не ставятся (так как мантейнеры их не пересобрали), то мы ставим зависимость.
Если мы хотим иметь пакеты, которые ставятся, а после этого или работают, или нет (причем, это неизвестно - нам об
этом напишут багрепорты), то не ставим. Плюс мы будем иметь (из-за непонятного поведения apt-get) правильные
пакеты, которые работали бы, если бы apt-get собрал-таки их с правильным питоном. Примеры были и с моими
пакетами, и даже - если мне на изменяет память - с пакетами MHZ. Причем всплывали эти примеры ой как не скоро.

Короче отказавшись от зависимости мы не приобретаем ничего. А теряем стабильность как сизифа, так и диструбутивов
на его основе.

PS: Что в одном случае, что в другом - пересборка требует робота. Ну будет робот чуть более сложным, проблем-то.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Mikhail Zabaluev]

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

В Пнд, 14/03/2005 в 23:29 +0300, Andrey Orlov пишет:
> > > Я ранее уже говорил, что делать _исходный_ пакет зависимым от среды
> > > сборки -- порочная практика.
> > Ну, возможно, следует ограничить привязку
> > python-devel'ом, а версию этуму python-devel'у проставлять только
> > в случае "явной привязки", т.е. --with pythonXY.
> 
> Это уже обсуждалось неоднократно. Если мы хотим иметь набор питоновских пакетов, которые
> работают или не ставятся (так как мантейнеры их не пересобрали), то мы ставим зависимость.
> Если мы хотим иметь пакеты, которые ставятся, а после этого или работают, или нет (причем, это неизвестно - нам об
> этом напишут багрепорты), то не ставим. Плюс мы будем иметь (из-за непонятного поведения apt-get) правильные
> пакеты, которые работали бы, если бы apt-get собрал-таки их с правильным питоном.

С бинарными пакетами все понятно, схема работает и сразу видно, каких
maintainer'ов нужно пинать или куда робота натравить.

Непонятно, зачем прибивать _исходные_ пакеты гвоздями к версии python,
существовавшей в системе на момент создания исходного пакета. Это
1)нелогично; и 2)мешает роботизированной пересборке с новым python.

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Alexey Morozov]

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

On Mon, Mar 14, 2005 at 11:29:44PM +0300, Andrey Orlov wrote:
> > Ну, возможно, следует ограничить привязку
> > python-devel'ом, а версию этуму python-devel'у проставлять только
> > в случае "явной привязки", т.е. --with pythonXY.
> Это уже обсуждалось неоднократно. Если мы хотим иметь набор питоновских пакетов, которые
> работают или не ставятся (так как мантейнеры их не пересобрали), то мы ставим зависимость.

Андрей, речь про _сборочную_ зависимость.
Про зависимости "бинарного пакета" речи и не идет, там, кажется, сейчас
все корректно с логической точки зрения.

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



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

Re: [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 ---
----------------------------------------

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

[Alexey I. Froloff]

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

* Andrey Orlov <cray@> [050315 21:58]:
> 2. hasher (вернее apt-get) собирая сборочную среду имеет
> тенденцию вытаскивать не тот python, который нужен. Т.е. не
> последний.
Повторяю вопрос - зачем держать в дистрибутиве несколько питонов?
Ради удобства мантейнера этого питона?

-- 
Regards, Sir Raorn.
-------------------
Не надо совмещать простую задачу со сложной.
		-- ldv in devel@

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

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

[Alexey Morozov]

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

On Wed, Mar 16, 2005 at 09:41:23AM +0300, Alexey I. Froloff wrote:
> * Andrey Orlov <cray@> [050315 21:58]:
> > 2. hasher (вернее apt-get) собирая сборочную среду имеет
> > тенденцию вытаскивать не тот python, который нужен. Т.е. не
> > последний.
> Повторяю вопрос - зачем держать в дистрибутиве несколько питонов?
> Ради удобства мантейнера этого питона?
Нет. На период апгрейда, по большому счету.
А апгрейд, судя по некоторым обидным пакетам, может затянуться.


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

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

[Michael Shigorin]

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

On Wed, Mar 16, 2005 at 01:26:00PM +0600, Alexey Morozov wrote:
> > Повторяю вопрос - зачем держать в дистрибутиве несколько питонов?
> > Ради удобства мантейнера этого питона?
> Нет. На период апгрейда, по большому счету.
> А апгрейд, судя по некоторым обидным пакетам, может затянуться.

А они этому помогают или мешают?  То, что не пересобрано -- и так
и так или холдится, или выносится, или пересобирается.

Бишь есть ли сейчас реальные пользователи нескольких версий
питона на одной системе одновременно? (наверное, в sisyphus@)

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

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

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

[Ivan Fedorov]

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

Michael Shigorin пишет:
> On Wed, Mar 16, 2005 at 01:26:00PM +0600, Alexey Morozov wrote:
> 
>>>Повторяю вопрос - зачем держать в дистрибутиве несколько питонов?
>>>Ради удобства мантейнера этого питона?
>>
>>Нет. На период апгрейда, по большому счету.
>>А апгрейд, судя по некоторым обидным пакетам, может затянуться.
> 
> 
> А они этому помогают или мешают?  То, что не пересобрано -- и так
> и так или холдится, или выносится, или пересобирается.
В orphaned и точка.

> Бишь есть ли сейчас реальные пользователи нескольких версий
> питона на одной системе одновременно? (наверное, в sisyphus@)
Я, но у меня ситуация особенная. У меня еще и 2.1 есть в /opt.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Andrey Orlov]

On Wednesday 16 March 2005 09:41, Alexey I. Froloff wrote:
> * Andrey Orlov <cray@> [050315 21:58]:
> > 2. hasher (вернее apt-get) собирая сборочную среду имеет
> > тенденцию вытаскивать не тот python, который нужен. Т.е. не
> > последний.
> Повторяю вопрос - зачем держать в дистрибутиве несколько питонов?
> Ради удобства мантейнера этого питона?

До чего доводит нежелание разобраться в сути проблемы. До того, что мантейнера
питона, которого только ленивый не пнул два года назад за желание убрать старые
питоны из дистрибутива,  вы обвиняете в том, что это именно его идея. Забавно
это слышать, вы ведь кажется даже фортунку мантейнера питона цитировали, которая
явно демонстрирует его отношение к трем питонам в дистрибутиве.

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

С моей точки зрения, держать несколько питонов - полный идиотизм, и я 
прилагаю массу усилий для того, что бы все пакеты работали именно с последним питоном. 
За что имел немало проблем, в частности с небезызвестным Zope. И все это действительно работает.

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

Мне кажется, что наша беседа станет существенно более конструктивна, если вы 
прочитаете-таки десять страниц python policy / faq, куда вас отправляют за эту неделю третий раз. И не 
надо будет "повторять вопрос". Их "часто" повторяют, и именно для таких повторяющих FAQ и написано.

PS: Кроме того, строго говоря, мы держим питоны не в дистрибутиве, а сизифе. В дистирибутивы
на основе сизифа входит только один python.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Alexey I. Froloff]

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

* Andrey Orlov <cray@> [050316 10:52]:
> > > 2. hasher (вернее apt-get) собирая сборочную среду имеет
> > > тенденцию вытаскивать не тот python, который нужен. Т.е. не
> > > последний.
> > Повторяю вопрос - зачем держать в дистрибутиве несколько питонов?
> > Ради удобства мантейнера этого питона?
> Мне кажется, что наша беседа станет существенно более
> конструктивна, если вы прочитаете-таки десять страниц python
> policy / faq, куда вас отправляют за эту неделю третий раз. И
> не надо будет "повторять вопрос". Их "часто" повторяют, и
> именно для таких повторяющих FAQ и написано.
Мне, как человеку, не пользующимся rpm-build-python, это
абсолютно ничего не даст:

$ grep -rl libpython /usr/share/doc/rpm-build-python-0.21 
zsh: 30232 exit 1     grep -rl libpython /usr/share/doc/rpm-build-python-0.21

Мне нужно держать свежий puthon-devel и две версии
libpython*.so.* чтобы слинковать vim с этой библиотекой.  Да фиг
с ним, с python-devel, соберу в sandman.  Две версии
libpython*.so.* чтобы у меня не выносилось полситемы.  Неужели я
так много прошу?

-- 
Regards, Sir Raorn.
-------------------
>Я вот думаю: как считает мэйнтейнер, может мне перестать скулить и
>навешать на него кучу выловленных багов и не-до-фич?
Вообще, это в любом случае было бы правильно.
		-- aen in sisyphus@

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

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

[Andrey Orlov]

On Wednesday 16 March 2005 11:48, Alexey I. Froloff wrote:
> > не надо будет "повторять вопрос". Их "часто" повторяют, и
> > именно для таких повторяющих FAQ и написано.
> Мне, как человеку, не пользующимся rpm-build-python, это
> абсолютно ничего не даст:

Оно написано не для тех, ктол пользуется rpm-build-python, а для тех,
кто пользуется python. Вы пользуетесь python - вам стоит это прочитать.
 
> $ grep -rl libpython /usr/share/doc/rpm-build-python-0.21 
> zsh: 30232 exit 1     grep -rl libpython /usr/share/doc/rpm-build-python-0.21

Да, действительно. Про libpython вы вопросы еще не задавали. А вот на предыдущие вопросы ответы там есть.

> Мне нужно держать свежий puthon-devel и две версии
> libpython*.so.* чтобы слинковать vim с этой библиотекой.  Да фиг

Две - это libpython2.3.so* & libpython2.4.so* ? А зачем вам сборка с libpython2.3*? Я не вижу
необходимости в поддержке  софта под два питона, вы, как я понял, тоже, а собирать зачем-то
хотите с libpython2.3. Ваши стремления мне непонятны, все-таки попробуйте определится что вы хотите.

> с ним, с python-devel, соберу в sandman.  Две версии
> libpython*.so.* чтобы у меня не выносилось полситемы. 

Как это отразится на выносе полсистемы? 

> Неужели я  так много прошу?

Собственно, чего вы хотите, установить libpython2.3.so* и libpython2.4.so* одновременно? 
Нет проблем, установите. В моем сборочно-тестовом V-сервере они установлены одновременно, 
кстати так же как python2.3-dev с python2.4-dev. Видимо, вам нужно сделать так: 

apt-get install python-relaxed 
apt-get install python2.3-relaxed
apt-get install python-dev python2.4-dev 

Все. Вы получили то что хотели, или я опять чего-то не понял? 

Кстати, в полиси и в FAQ этот вопрос подробно разжеван. Кажется. Хотя libpython.so 
там не упоминается. Собственно, также как readline.so и неск. сотен других файлов.
Вы уже задавали вопрос, ответ на который записан выше, и вас уже посылали на FAQ и полиси,
которые вы почему-то упорно не хотите прочитать.


PS: Чбы не возникало ненужных инсинуаций. Установлены не потому, что мне это "удобно" (меня это достало еще со времени redhat),
и не потому, что  этим пользуюсь
для сборки (я неоднократно заявлял, что музейные экспонаты меня не интересуют),
а потому, что я вынужден тестировать, то, что это возможно.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Alexey I. Froloff]

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

* Andrey Orlov <cray@> [050316 14:30]:
> Две - это libpython2.3.so* & libpython2.4.so* ? А зачем вам
> сборка с libpython2.3*? Я не вижу необходимости в поддержке
> софта под два питона, вы, как я понял, тоже, а собирать
> зачем-то хотите с libpython2.3. Ваши стремления мне непонятны,
> все-таки попробуйте определится что вы хотите.
Я хочу собрать и установить vim с libpython2.4.so.1.0.  При этом
я хочуб чтобы apt не вынес мне openoffice и половину гнома из-за
взаимных конфликтов в других пакетах.

Я хочу сделать apt-get install libpython2.4.so.1.0 и не иметь
никому мозги.  При этом libpython2.3.so.1.0 мне всё ещё нужна по
зависимостям.

Получается:

puthon2.4-base хочет python=2.4
puthon2.3-base хочет python=2.3
Пол гнома хочет python-strict, который хочет только одного
питона.

Либо я выношу всё, что хочет python-strict, либо имею только одну
libpython2.x.so.1.0.

Мне проще оторвать поддержку python от vim.  Но куда посылать
тех, кому нужен vim с pythoninterp?

-- 
Regards, Sir Raorn.
-------------------
Концепция целостного репозитария такова, что статическим библиотекам
в нем не место (имеются исключения).  Помимо разделяемости, динамические
библиотеки дают прозрачные зависимости, возможность асинхронной
поддержки пакетов и т.д.
		-- at in devel@

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

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

[Andrey Orlov]

On Wednesday 16 March 2005 14:43, Alexey I. Froloff wrote:
> * Andrey Orlov <cray@> [050316 14:30]:
> > Две - это libpython2.3.so* & libpython2.4.so* ? А зачем вам
> > сборка с libpython2.3*? Я не вижу необходимости в поддержке
> > софта под два питона, вы, как я понял, тоже, а собирать
> > зачем-то хотите с libpython2.3. Ваши стремления мне непонятны,
> > все-таки попробуйте определится что вы хотите.
> Я хочу собрать и установить vim с libpython2.4.so.1.0.  При этом
> я хочуб чтобы apt не вынес мне openoffice и половину гнома из-за
> взаимных конфликтов в других пакетах.
> 
> Я хочу сделать apt-get install libpython2.4.so.1.0 и не иметь
> никому мозги.  При этом libpython2.3.so.1.0 мне всё ещё нужна по
> зависимостям.

Я так понимаю, что libpython2.3.so.1.0 нужна по зависимостям вам, 
а не vim? Т.е. какие-то пакеты, которые вам нужны ее хотят? 
И, кроме того, есть пакеты которые хотят python-strict = 2.3, которые
вам тоже нужны. Как вы понимаете, не зависимо от того, как мы обставляем
переход на новый питон (с десятью питонами или без них), в чистом виде это не 
решается. Мне вот тоже регулярно нужен какой-то пакетик для сборки очередного python и типа
того, установка которого выносит мне полкде. Обычно за пару недель все что надо пересобирают,
и это решается. А так как собирать мне нужно сейчас, а не через пару недель, то я собираю в чруте.

Теперь подробно. 

 1. Вы ставите чрут (или vserver) с минимумом пкетов, в т.ч. python-dev = 2.4 и спокойно собираете
vim, который отправляется в инкоминг. Насколько я понимаю, он уже там. У нас есть какая-то проблема 
с последующим апгрейдом - я с этой  проблемой обещаю вам разобраться. До сих пор не занялся, 
так как занят цитированием полиси для вас, равно как ранее написанных писем.

2. После этого вы смотрите, какие пакеты, из тех, которые вам нужны хотят по прежнему python2.3 и просите
мантейнеров пересобрать. Или пересобираете сами, попросив мантейнеров принять вашу сборку.

3. Как только при очередном dist-upgrade вы увидитие, что вам не выносит полсистемы ,вы все ставите. 

Проблем я вижу две: договорится с мантейнерами, но, как мы с Димой уже обсудили, тут все просто 29марта
так или иначе вопрос будет решен, и непонятное поведение apt-get, который вместо одного возможного решения
системы зависимостей выбрал другое. Тоже возможное. Как обойти я знаю: скорее всего, если вы явно укажете
apt-get install vim-enhanced, а уж потом dist-upgrade, у вас все встанет. Почему apt-get нашел другое решения - я попробую 
разобраться, где проблема я догадваюсь, но наперед говорить не хочу.

Если же вам libpython2.3 нужна для чего-то еще, то .... вам придется чем-то пожертвовать.

-- 
WthBstRgrds --
 -- Andrey Orlov --

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

[Alexey I. Froloff]

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

* Andrey Orlov <cray@> [050316 16:12]:
> Теперь подробно. 
[..skip..]
> Если же вам libpython2.3 нужна для чего-то еще, то .... вам
> придется чем-то пожертвовать.
Ну, мы вчера в jabber этот вопрос уже обсуждали...

Если питон один, то почему их три?  Зачем нужно держать в
репозитарии три версии питона? (Андрей, если напрягает, пропусти
пять абзацев ;-)

$ locate -r SRPMS/python-\?2
/var/ftp/pub/distributions/ALTLinux/Sisyphus/files/SRPMS/python-2.4.0-alt5.src.rpm
/var/ftp/pub/distributions/ALTLinux/Sisyphus/files/SRPMS/python2.3-2.3.4-alt7.src.rpm
/var/ftp/pub/distributions/ALTLinux/Sisyphus/files/SRPMS/python22-2.2.3-alt8.1.1.src.rpm

Для меня количество питонов определется количеством пакетов,
провайдящих python-devel - количество вариантов сборки чего-либо.
Сейчас выбор варианта делается через зависимость на
python-devel=%_python_version...

После появления python-2.4.0 и переименования python-2.3.x ->
python2.3 все попытки собрать пакеты с python2.3 были об'явлены
противозаконными и нарушающими права человека.  Отсюда
получается, что есть смысл держать в репозитарии один
пакет python-devel последней версии.

Едем дальше.  Все пакеты, предоставляющие или зависимые от
питоньих модулей имеют версию питона в зависимостях
(pyhtonX.Y(blah)).  Отсюда получается, что python2.3 нужен только
на момент перехода на новый питон, чтобы не плодить сто тыщщ
мульёнов unmet'ов.

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


Далее, зависимость на libpythonX.Y.so.x.y как правило означает
что пакет может использовать какие-то возможности языка python.
Как правило это опционально.  См. напр. vim, OOo, xchat,
gnumeric, zapping...

Сейчас libpythonX.Y.so.x.y лежит в python-base, python-base сам
по себе требует python=%__python_version, python-strict
конфликтует с python не своей версии.

Если развернуть зависимости следующим образом:

python-base может быть установлен сам по себе.
python хочет python-base=%__python_version
python-strict по прежнему конфликтует с python не своей версии.

Это решит следующие проблемы:

+ установка пакета, использующего embedded python не приведёт к
установке python-strict/relaxed/whatever если не требуются
дополнительные модули (как правило задействуются они из
вспомогательных скриптов на языке python).

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

Вариант, когда у пакета есть зависимости на libpythonX.Y.so.x.y и
одновременно на pythonZ.C(blah) мне представляется маловероятным.


По поводу автоматической пересборки...  Да, я помню что некоторые
пакеты не работали при после автоматической пересборки с новым
python (2.2 это был кажется?), но у программ, которые встраивают
в себя питон немного другая ситуация.

Если изменился API программа просто автоматически не
пересоберётся, о чём мантейнер будет уведомлён и уже сам будет с
этим разбираться.  Если программа пересобралась, она запустится.
Я не думаю, что Гвидо настолько отмороженый на голову, чтобы
делать какие-то радикальные изменения, незаметные обычному
пользователю libpython (как это недавно случилось с libncurses)...

Поэтому есть смысл натравливать QA робота на все пакеты,
зависящие от libpythonX.Y.so.x.y сразу после появления нового
python в репозитарии.  Возможно с поправкой - зависящие от
libpythonX.Y.so.x.y и не зависясище от pythonX.Y(*)...

-- 
Regards, Sir Raorn.
-------------------
> Помогите решить проблему с проигрыванием midi. KMid и playmidi
...все равно не переиграют TiMidity++? ;-)
		-- mike in community@

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

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

[Andrey Orlov]

On Thursday 17 March 2005 10:17, Alexey I. Froloff wrote:
> Если питон один, то почему их три?  Зачем нужно держать в
> репозитарии три версии питона? (Андрей, если напрягает, пропусти
> пять абзацев ;-)

Я пропустил все письмо. Твое предложение я понял. Просто я не понимаю,
какую проблему это решит и почему. Я вижу только добавление проблем - скажем, 
никто не планирует что libpython2.3 войдет в дистрибутив, а значит ваш vim опять окажется за бортом. 
Имеющаяся проблема решается пересборкой остальных пакетов.  Видимо, вам стоит просто подждать
пока мы ее решим, а не устраивать панику.

-- 
WthBstRgrds --
 -- Andrey Orlov --

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

[Michael Shigorin]

On Thu, Mar 17, 2005 at 10:53:24AM +0300, Andrey Orlov wrote:
> Я пропустил все письмо. Твое предложение я понял. Просто я не
> понимаю, какую проблему это решит и почему.

Если убрать старые devel, то с ними не получится собраться.
При этом compact code будет доступен.

Или смысл старых питонов -- только вместе с devel'ами?

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

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

[Andrey Orlov]

On Thursday 17 March 2005 11:01, Michael Shigorin wrote:
> On Thu, Mar 17, 2005 at 10:53:24AM +0300, Andrey Orlov wrote:
> > Я пропустил все письмо. Твое предложение я понял. Просто я не
> > понимаю, какую проблему это решит и почему.
> 
> Если убрать старые devel, то с ними не получится собраться.
> При этом compact code будет доступен.
> 
> Или смысл старых питонов -- только вместе с devel'ами?

Так оно же вроде собралось с libpython2.4, зачем теперь с 2.3 еще собирать?

> 

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Michael Shigorin]

On Thu, Mar 17, 2005 at 11:28:19PM +0300, Andrey Orlov wrote:
> > > Я пропустил все письмо. Твое предложение я понял. Просто я
> > > не понимаю, какую проблему это решит и почему.
> > Если убрать старые devel, то с ними не получится собраться.
> > При этом compact code будет доступен.
> > Или смысл старых питонов -- только вместе с devel'ами?
> Так оно же вроде собралось с libpython2.4, зачем теперь с 2.3
> еще собирать?

*sigh*.  Перечитай письмо сэра Раорна, посмотри и подумай -- мне
кажется, что это скорее здраво -- уносить старые python*-dev*,
чтобы с ними *точно*, ни при каких обстоятельствах и глюках апта
уже ничто не пыталось собраться как класс.

Разумеется, если это не лишит [существенной части] смысла
нахождение старых питонов в репозитории вообще.

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

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

[Alexey I. Froloff]

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

* Andrey Orlov <cray@> [050317 10:54]:
> Я пропустил все письмо. Твое предложение я понял. Просто я не
> понимаю, какую проблему это решит и почему.
В общем всех кто будет хотеть поддержку питона в vim я буду
отправлять к тебе.  Мне такое соотношение размеров геммороя к
количесву пакетов кажется завышеным.

-- 
Regards, Sir Raorn.
-------------------
Последние знакомые мандраководы свалили на дебиан (достал их mdk на
сервере), предпоследние -- на альт и дебиан ещё года два назад.

Плюшки в фишках, видать, жмут.
		-- mike in devel@

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

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

[Anton Farygin]

Andrey Orlov wrote:

>On Thursday 17 March 2005 10:17, Alexey I. Froloff wrote:
>  
>
>>Если питон один, то почему их три?  Зачем нужно держать в
>>репозитарии три версии питона? (Андрей, если напрягает, пропусти
>>пять абзацев ;-)
>>    
>>
>
>Я пропустил все письмо. Твое предложение я понял. Просто я не понимаю,
>какую проблему это решит и почему. Я вижу только добавление проблем - скажем, 
>никто не планирует что libpython2.3 войдет в дистрибутив, а значит ваш vim опять окажется за бортом. 
>Имеющаяся проблема решается пересборкой остальных пакетов.  Видимо, вам стоит просто подждать
>пока мы ее решим, а не устраивать панику.
>
>  
>
Я бы сказал наоборот - если мы запланируем, что vim войдет в 
дистрибутив, то туда автоматом попадет и libpython2.3

Т.е. - нужно понимать, что в этом случае libpyhton2.3 всего лишь 
инструмент, необходимый для функционирования vim'а. А сам по себе он 
никому не нужен.

Rgds,
Rider

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

[Andrey Orlov]

On Thursday 17 March 2005 11:37, Anton Farygin wrote:
> Я бы сказал наоборот - если мы запланируем, что vim войдет в 
> дистрибутив, то туда автоматом попадет и libpython2.3
> 
> Т.е. - нужно понимать, что в этом случае libpyhton2.3 всего лишь 
> инструмент, необходимый для функционирования vim'а. А сам по себе он 
> никому не нужен.

Если я правильно понимаю, то vim прекрасно собирается и работает с libpython2.4.
Во всяком случае в таком виде он лежит в сизифе и, вроде, работает. Я им не пользуюсь,
мне трудно оценить. А вот зачем к нему пытаются прикрутить libpython2.3 вместе с libpython2.4 мне, 
видимо, не дано понять.

-- 
WthBstRgrds --
 -- Andrey Orlov --

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

[Alexey Morozov]

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

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


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

Re: [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 --

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

[Andrey Orlov]

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

[skip]

Все скипнутые аргументы я прекрасно знаю, и собственно мы  с тобой 
вместе потратили немало сил, что бы это было так.

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

1. Пакет b провайдит python2.4(b)

2. При байт-компиляции был использован python2.4

Если кратко, то пакет пересобран с python2.4. А вот тот
замечательный факт, что запустив python2.3, я смогу сказать
import b и убедится, что b работает - мне совершенно не интересен.
Так как моя программа c __не__работает__, не работает из-за пакета
b и я либо пишу багрепорт, либо персобираю его сам. Т.е. пакет, пересобранный
с неправильным питоном не работоспособен.

Мантейнер пакета b имеет шансы отбится от моих претензий, если он решил (по каким-то
ему ведомым причинам), что пакет b не пригоден для работы с python2.4. Но если он
положил в incoming пакет, пересобранный с python2.4, а ны выходе получил пакет пересобранный
с python2.3, и багрепорт от держателя пакета c впридачу - его праведному гневу на сборочную
среду не будет границ, он вобъет BuildReq python-devel = 2.4  в спек, и будет это отстаивать. Как
собственно я это и делаю.

> > 2. hasher (вернее apt-get) собирая сборочную среду имеет тенденцию
> > вытаскивать не тот python, который нужен. Т.е. не последний. 
> А вот это, наверное, другая проблема, но, кажется, ты пытаешься
> рубить хвост змея горыныча, вместо того, чтобы рубить (и прижигать еще,
> кажется, надо было) головы. Тогда это так и стоит объявлять:
> 
> due to deficiency of apt/hasher we have to explictly bind...

Я так и пишу.

> > То что я имею проявления этой ошибки дома каждый день - я об этом
> > просто молчу, LDV научил меня с ней бороться, я это уже делаю на автомате.
> Может, вам, эта, собраться вдвоем и родить, гхм, гомункула, который
> будет делать это за вас? ;-)

Однажды, я решил что хрена ли мне блин, и не такое правили, и открыл исходники rpm / apt. 
Я их внимательно изучил и понял, что это какие-то не те исходники. Какой-то другоей программы,
не той к котрой я привык. Тогда я наложил все патчи. И увидел уже совсем другие исходники.
И после того, как я их изучил. У меня не возникло ни малейшего желания изменять в них хоть один байт.
Я не тот человек, которому настолько интересен apt / rpm, что бы положить на них жизнь

> Могу поручиться, что твой любимый писатель в детстве - Жюль Верн.

Циолковский.

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

Построил себе мавзолей :(.

> :-) Попробую. (С некоторой досадой) Слушай, а это же придется читать то,
> что мы там с тобой написали, да?

Ну да, ну да...

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Mikhail Zabaluev]

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

В Срд, 16/03/2005 в 11:46 +0300, Andrey Orlov пишет:
> Мантейнер пакета b имеет шансы отбится от моих претензий, если он решил (по каким-то
> ему ведомым причинам), что пакет b не пригоден для работы с python2.4. Но если он
> положил в incoming пакет, пересобранный с python2.4, а ны выходе получил пакет пересобранный
> с python2.3, и багрепорт от держателя пакета c впридачу - его праведному гневу на сборочную
> среду не будет границ, он вобъет BuildReq python-devel = 2.4  в спек, и будет это отстаивать. Как
> собственно я это и делаю.

Возможен другой вариант (как у меня на днях): майнтейнер пакета печально
улыбнется, в очередной раз осознав несовершенство мира и тщету попыток
его исправить, и проставит BuildRequires: python-devel >= 2.4 (вдруг к
следующему апгрейду apt все-таки доведут до ума?). А с двумя другими
пакетами, неприбитыми к определенной версии python-devel (libxml2 и
libxslt) и вовсе поимеет нуль проблем, пересобрав их и убедившись, что
hasher подхватил python 2.4.

Но Зло в моем представлении даже не явный BuildRequires на =, а его
неявная генерация с использованием %__python_version.
Отдайте этот ломик майнтейнеру, пусть редактирует руками. Мы разумные
люди и можем следовать полиси. По крайней мере стараемся.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Andrey Orlov]

On Thursday 17 March 2005 00:18, Mikhail Zabaluev wrote:
> Но Зло в моем представлении даже не явный BuildRequires на =, а его
> неявная генерация с использованием %__python_version.

Опишите, пожалуйста, гипотетическую ситуацию, в которой пакет собранный с %__python_version = 2.3 (например),
не должен иметь зависимость BuildReq: python-devel = 2.3 и должен иметь зависимость BuildReq: python-devel = 2.4 (например).
Не спора ради, а просто интересно. Я как ни стараюсь - не могу не только придумать такую ситуацию, но не могу 
даже представить как таким способом можно получить работающий пакет. 

Что до предложенного вами >= ... То дело в том, что тогда пакет может оказаться пересобран с неправильным питоном более старшей
версии. Сейчас такого уже нет. Но последние 8мь месяцев - был. Пререлиз 2.4, а потом и сам 2.4.0. А в ближайшем будущем он опять появиться.
Пререлиз 2.5 :). И то, и другое лежало  и будет лежать, как минимум, в дедвле. Который тоже собирается хешер + apt и c которым ровно те же 
проблемы. 

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Mikhail Zabaluev]

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

В Чтв, 17/03/2005 в 00:44 +0300, Andrey Orlov пишет:
> On Thursday 17 March 2005 00:18, Mikhail Zabaluev wrote:
> > Но Зло в моем представлении даже не явный BuildRequires на =, а его
> > неявная генерация с использованием %__python_version.
> 
> Опишите, пожалуйста, гипотетическую ситуацию, в которой пакет собранный с %__python_version = 2.3 (например),
> не должен иметь зависимость BuildReq: python-devel = 2.3 и должен иметь зависимость BuildReq: python-devel = 2.4 (например).

Есть совершенно реальные пакеты, имеющие BuildRequires: python-devel
(без версии). Недавно пересобранные с 2.4 и выложенные в Sisyphus,
изжоги пока не вызывали. Я предпочитаю иметь их в таком виде (исходные
пакеты насколько возможно агностичны к среде сборки) и решать проблемы
по мере их поступления.

> Не спора ради, а просто интересно. Я как ни стараюсь - не могу не только придумать такую ситуацию, но не могу 
> даже представить как таким способом можно получить работающий пакет. 
> 
> Что до предложенного вами >= ... То дело в том, что тогда пакет может оказаться пересобран с неправильным питоном более старшей
> версии. Сейчас такого уже нет. Но последние 8мь месяцев - был. Пререлиз 2.4, а потом и сам 2.4.0. А в ближайшем будущем он опять появиться.
> Пререлиз 2.5 :). И то, и другое лежало  и будет лежать, как минимум, в дедвле. Который тоже собирается хешер + apt и c которым ровно те же 
> проблемы. 

Почему-то пакет, требовавший ранее >= 2.3, а сейчас >= 2.4, не вызывал
проблем ни в Daedalus, ни в Sisyphus. Коль скоро у нас в Sisyphus (и в
Daedalus) отныные всегда находится одна версия, откуда при сборке
взяться неправильной?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Andrey Orlov]

On Friday 18 March 2005 02:33, Mikhail Zabaluev wrote:
> В Чтв, 17/03/2005 в 00:44 +0300, Andrey Orlov пишет:
> > On Thursday 17 March 2005 00:18, Mikhail Zabaluev wrote:
> > > Но Зло в моем представлении даже не явный BuildRequires на =, а его
> > > неявная генерация с использованием %__python_version.
> > 
> > Опишите, пожалуйста, гипотетическую ситуацию, в которой пакет собранный с %__python_version = 2.3 (например),
> > не должен иметь зависимость BuildReq: python-devel = 2.3 и должен иметь зависимость BuildReq: python-devel = 2.4 (например).
> 
> Есть совершенно реальные пакеты, имеющие BuildRequires: python-devel
> (без версии). Недавно пересобранные с 2.4 и выложенные в Sisyphus,
> изжоги пока не вызывали. Я предпочитаю иметь их в таком виде (исходные
> пакеты насколько возможно агностичны к среде сборки) и решать проблемы
> по мере их поступления.

Вы не ответили на вопрос. Вы сказали, что хотите
указывать в зависимости номер версии вручную (очевидно, отличный от %__python_version), так как
это вам полезно. Я попросил описать для чего, вы начинаете увиливать. Я правильно вас
понимаю, что вы не можете ответить на вопрос и ваше утверждение о полезности я могу
считать ошибочным? И что вы не можете объяснить, зачем вам нужна возможность указать
номер версии в зависимости вручную?

> проблем ни в Daedalus, ни в Sisyphus. Коль скоро у нас в Sisyphus (и в
> Daedalus) отныные всегда находится одна версия, откуда при сборке
> взяться неправильной?

С какого перепугу вдруг там всегда находится одна версия? Там сейчас, например, находится три версии.
И пока что я не вижу причины это изменить. А уж то, что в дедале вторая версия будет лежать практически всегда 
- я совершенно не сомневаюсь. Мне пререлизы очень нужны, а держать пререлиз в сизифе я, по понятным причинам,
не хочу.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Mikhail Zabaluev]

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

В Птн, 18/03/2005 в 03:09 +0300, Andrey Orlov пишет:
> Вы не ответили на вопрос. Вы сказали, что хотите
> указывать в зависимости номер версии вручную (очевидно, отличный от %__python_version), так как
> это вам полезно.

Я ответил: я хочу чтобы номером версии в BuildRequires управлял я, а не
макрос %__python_version, которого в типичном spec'е даже нет в явном
виде. Подробнее: таким образом, последовательность rpmi -bi ...;
rpmbuild -bs ... в отсутствие изменения spec дает пакет, практически
идентичный исходному. Нет никаких подводных камней с BuildRequires,
изменяемым без моего ведома.
Когда автоматизация начинает претендовать на то, чтобы быть умнее
человека, это всегда выходит плохо.

> С какого перепугу вдруг там всегда находится одна версия? Там сейчас, например, находится три версии.

Значит, мои пакеты это пережили. Проблемы, столь много говоримые о, не
материализовались.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Andrey Orlov]

On Friday 18 March 2005 11:03, Mikhail Zabaluev wrote:
> В Птн, 18/03/2005 в 03:09 +0300, Andrey Orlov пишет:
> > Вы не ответили на вопрос. Вы сказали, что хотите
> > указывать в зависимости номер версии вручную (очевидно, отличный от %__python_version), так как
> > это вам полезно.
> 
> Я ответил: я хочу чтобы номером версии в BuildRequires управлял я, а не

Нет. Вы не ответили. Ну давайте я вам разжую воппрос еще раз.

> макрос %__python_version, которого в типичном spec'е даже нет в явном
> виде. 

Итак. Вы хотите иметь возможность установить номер версии в 

BuildRequires: python-devel = ?.? 

Утверждая, что это вам полезно (это утверждение можете поискать в ваших предыдущих письмах).

Возможны два варианта:

1. Вы устанавливаете номер версии равный %__python_version. Тогда, как вы понимаете,
утверждение о том, что это вам полезно, неверно: вы получаете идентичный пакет, не лучше не хуже.

2. Вы устанавливаете номер версии не равный %__python_version, опять же, утверждая что это вам полезно.
Я, как я уже написал, не могу понять не только зачем это нужно, но даже не могу понять как таким образом
можно получить работоспособный пакет. Тем не менее, оставив в стороне (пока) вопрос работоспособности
полученного пакета, я попросил вас привести пример, когда такая возможность вам необходима, справедливо
полагая, что если для вас это действительно так полезно, то пример не заставит себя ждать.

А вместо этого я вижу вот такие голословные утверждения:

> Когда автоматизация начинает претендовать на то, чтобы быть умнее
> человека, это всегда выходит плохо.

Похоже, вы свое мнение доказать не можете. Конечно, невозможность доказать обратную теорему сомнительный
аргумент в пользу самой теоремы :), но до тех пор, пока вы не подкрепите ваше словоблудие конкретным примером,
я буду подозревать что оно не верное. 

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

> > С какого перепугу вдруг там всегда находится одна версия? Там сейчас, например, находится три версии.
> 
> Значит, мои пакеты это пережили. Проблемы, столь много говоримые о, не
> материализовались.

Тем не менее, ошибка воспроизводима. Поскольку LDV подтвердил ее наличие, когда мы с ним это обсуждали,
дискутировать на эту тему с вами я не буду. Моя позиция такая: будет исправлена ошибка - я буду думать,
не повредит ли нам убирание зависимости, и если не повредит - ослаблю это требование в полиси.
Не будет - словоблудие мне неинтересно. Так что хотите добится результата - хватайте исходники apt-get и вперед.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

Re: [devel] apt-rpm issue

[Dmitry V. Levin]

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

On Sat, Mar 19, 2005 at 02:39:17PM +0300, Andrey Orlov wrote:
> Тем не менее, ошибка воспроизводима. Поскольку LDV подтвердил ее наличие, когда мы с ним это обсуждали,

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


-- 
ldv

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

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

[Andrey Orlov]

On Friday 11 March 2005 18:43, Dmitry V. Levin wrote:
> В принципе это возможно, об этом надо договориться с incoming@.
> 
> Технически это несколько сложнее обычного, поскольку у большинства
> исходных пакетов есть сборочная зависимость на "python-devel = 2.3".

Я в курсе. Отчасти потому и пишу. 

> Впрочем, для этого есть "hsh --query-req-prog".

:), ставя требование на зависимость "python-devel = 2.3" я не сомневался в том, что в случае необходимости
автоматической пересборки решение найдется. Я изучу вопрос.

2ALL: Пока что вопрос об автоматической пересборке не стоит. У меня просто академический интерес. 
Пожалуйста, пересоберите и протеструйте свои пакеты.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Dmitry V. Levin]

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

On Mon, Mar 14, 2005 at 12:31:25AM +0300, Andrey Orlov wrote:
> On Friday 11 March 2005 18:43, Dmitry V. Levin wrote:
> > В принципе это возможно, об этом надо договориться с incoming@.
> > 
> > Технически это несколько сложнее обычного, поскольку у большинства
> > исходных пакетов есть сборочная зависимость на "python-devel = 2.3".
> 
> Я в курсе. Отчасти потому и пишу. 
> 
> > Впрочем, для этого есть "hsh --query-req-prog".
> 
> :), ставя требование на зависимость "python-devel = 2.3" я не сомневался в том, что в случае необходимости
> автоматической пересборки решение найдется. Я изучу вопрос.

Честно говоря, я не вижу смысла в том, чтобы ставить барьеры в форме
сборочных зависимостей вида "python-devel = 2.3".
Даже робота это всё равно не остановит от того, чтобы собрать пакет
с тем питоном, который требуется, а человека тем более.
Сделать мантейнеров более сознательными с помощью таких трюков вряд ли
удастся.

> 2ALL: Пока что вопрос об автоматической пересборке не стоит. У меня просто академический интерес. 
> Пожалуйста, пересоберите и протеструйте свои пакеты.

По моему, это нереально.  Речь идёт о примерно 73 исходных пакетах.
Думаю, будет лучше, если через несколько дней всё, что не соберут
сознательные мантейнеры, пересоберёт робот.
Впрочем, если целью является не рабочий Сизиф а повышение сознательности
мантейнеров, то робота лучше вообще не испльзовать.


-- 
ldv

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

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

[Michael Shigorin]

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

On Mon, Mar 14, 2005 at 03:02:17AM +0300, Dmitry V. Levin wrote:
> Думаю, будет лучше, если через несколько дней всё, что не
> соберут сознательные мантейнеры, пересоберёт робот.

Мои, пожалуйста, роботу. :)

> Впрочем, если целью является не рабочий Сизиф а повышение
> сознательности мантейнеров, то робота лучше вообще не
> испльзовать.

И кнут -- тоже.

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

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

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

[Dmitry V. Levin]

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

On Mon, Mar 14, 2005 at 03:02:17AM +0300, Dmitry V. Levin wrote:
> On Mon, Mar 14, 2005 at 12:31:25AM +0300, Andrey Orlov wrote:
[...]
> > 2ALL: Пока что вопрос об автоматической пересборке не стоит. У меня просто академический интерес. 
> > Пожалуйста, пересоберите и протеструйте свои пакеты.
> 
> По моему, это нереально.  Речь идёт о примерно 73 исходных пакетах.

На самом деле речь идёт о примерно 128 исходных пакетах.


-- 
ldv

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

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

[Andrey Orlov]

On Monday 14 March 2005 03:02, Dmitry V. Levin wrote:
> Честно говоря, я не вижу смысла в том, чтобы ставить барьеры в форме
> сборочных зависимостей вида "python-devel = 2.3".
> Даже робота это всё равно не остановит от того, чтобы собрать пакет
> с тем питоном, который требуется, а человека тем более.

Я знаю, что робота не оснановит. Именно поэтому и говорю, что усложнение робота - 
несущественный аргумент. Зато это останавливает сборочную среду, основанную на
apt-get, от пересборки пакета не с тем питоном, который задумал мантейнер. Найдете
другое решение - ОК - а только я, вытащив несколько раз свои замечательные пакеты,
которые я собирал и тестировал с 2.3 пересобранными с 2.2. и __не__ работающими,
уверен в том, что убери мы сейчас это правило - и скоро я буду писать письма о том, что 
"я предупреждал". Мало того, явную установку версии вообще придумал не я,
это было еще до меня.  Я только последовал принятым на момент написания
полиси правилам, тем более что убедился уже в их необходимости.

> Сделать мантейнеров более сознательными с помощью таких трюков вряд ли
> удастся.

Я и не надеюсь. Просто, мое мнение, если мантейнер не может пересобрать пакет - пакет 
обсолетитсся и сбрасывается. Почему у нас для сборки с  bsddb одни правила,
а с python - другие (я имею ввиду сброс необновленных пакетов, а не зависимости)? 
Потому что из-за зависимостей на bsddb появляеются гарантированные
сбои в момент сборки? А не в момент эксплуатации? Вот благодаря зависимостям получаем
сбой в момент сборки. Дима, ты же не станешь запихивать в rpm пакет, у которого обломалась
компиляции? А ведь это можно сделать, как гладко обновлятся будет из сизифа.....

> > 2ALL: Пока что вопрос об автоматической пересборке не стоит. У меня просто академический интерес. 
> > Пожалуйста, пересоберите и протеструйте свои пакеты.
> 
> По моему, это нереально.  Речь идёт о примерно 73 исходных пакетах.
> Думаю, будет лучше, если через несколько дней всё, что не соберут
> сознательные мантейнеры, пересоберёт робот.

Согласен. Но дадим им пару недель, ОК?

> Впрочем, если целью является не рабочий Сизиф а повышение сознательности
> мантейнеров, то робота лучше вообще не испльзовать.

Меня не интересует сознательность. Меня просто хочется, чбы делая apt-get dist-upgrade я либо
сносил пакет, либо ставил работающий пакет. Не более.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Alexey I. Froloff]

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

* Andrey Orlov <cray@> [050314 23:53]:
> Мало того, явную установку версии вообще придумал не я, это
> было еще до меня.  Я только последовал принятым на момент
> написания полиси правилам, тем более что убедился уже в их
> необходимости.
А не будет проще избавиться от пакетов puthon-* и перевести всё
на python%__python_version?

Есть python2.3, есть python2.4.  У каждого есть свой -devel,
который провайдит python-devel = %__python_version.  В данный
момент времени в системе может стоять только один -devel.
Разруливать выбор нужного devel можно на уровне
/etc/apt/pkgpriorities - версия питона не так часто меняется, тем
более что сейчас там и так прописаны python-dev и
python-modules-tkinter...

Я слабо представляю ситуацию, когда на стабильной системе
необходимы два или более питона одновременно.

P.S.  Это я вспоминаю восресный dist-upgrade...  Когда python=2.3
сменил имя на python2.3, а python2.4 стал просто python настала
ЖОПА.  Незнаю, насколько она была похожа на тот самый редхат с
тремя питонами на борту ;-)

-- 
Regards,
Sir Raorn.

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

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

[Andrey Orlov]

On Tuesday 15 March 2005 01:18, Alexey I. Froloff wrote:
> А не будет проще избавиться от пакетов puthon-* и перевести всё
> на python%__python_version?
> 
> Есть python2.3, есть python2.4.  У каждого есть свой -devel,
> который провайдит python-devel = %__python_version.  В данный
> момент времени в системе может стоять только один -devel.

FAQ Q20 / A20. Это не работает. Так как есть - проще всего. Поверьте, все
такие предложения на эту тему я придумал и попробовал еще полтора года назад.
По крайней мере с весны прошлого года я ни одной новой для себя идеи 
на эту тему не слышал, я их все попробоавал и выбрал наиболее 
беспроблемный вариант.

> P.S.  Это я вспоминаю восресный dist-upgrade...  Когда python=2.3
> сменил имя на python2.3, а python2.4 стал просто python настала
> ЖОПА.  Незнаю, насколько она была похожа на тот самый редхат с
> тремя питонами на борту ;-)

Все решается оч. просто. Вы имеете установленным python-strict и тогда
ситуация точно такая, как вы хотите. Один питон. Я на своей машине имею именно так.
А для пересборки использую chroot или vserver - и в том, и в другом случае это съедает ~200 метров.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Alexey I. Froloff]

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

* Andrey Orlov <cray@> [050315 02:06]:
> > Есть python2.3, есть python2.4.  У каждого есть свой -devel,
> > который провайдит python-devel = %__python_version.  В данный
> > момент времени в системе может стоять только один -devel.
> FAQ Q20 / A20.
Это не тот случай.  python-dev -> python2.4-devel.

-- 
Regards, Sir Raorn.
-------------------
Скажите, в чём смысл написания локальных хаков-однодневок?
Разве нельзя определиться, где функция неправильно используется
или неправильно реализована и исправить проблему в корне?
А подобные исправления не оздоровляют атмосферу, это всего лишь
дезодоранты, которые заглушают запах, но не устраняют причину :(
		-- lav in sisyphus@

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

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

[Andrey Orlov]

On Tuesday 15 March 2005 09:35, Alexey I. Froloff wrote:
> * Andrey Orlov <cray@> [050315 02:06]:
> > > Есть python2.3, есть python2.4.  У каждого есть свой -devel,
> > > который провайдит python-devel = %__python_version.  В данный
> > > момент времени в системе может стоять только один -devel.
> > FAQ Q20 / A20.
> Это не тот случай.  python-dev -> python2.4-devel.

Это тот случай.

-- 
WthBstRgrds --
 -- Andrey Orlov --

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

[Dmitry V. Levin]

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

On Mon, Mar 14, 2005 at 11:43:48PM +0300, Andrey Orlov wrote:
> > По моему, это нереально.  Речь идёт о примерно 73 исходных пакетах.
> > Думаю, будет лучше, если через несколько дней всё, что не соберут
> > сознательные мантейнеры, пересоберёт робот.
> 
> Согласен. Но дадим им пару недель, ОК?

В любом случае пакеты, собранные более полугода назад, автоматической
пересборке подвергать не имеет смысла.


-- 
ldv

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

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

[Alexey Rusakov]

Dmitry V. Levin wrote:

>В любом случае пакеты, собранные более полугода назад, автоматической
>пересборке подвергать не имеет смысла.
>  
>
В случае программ на Python я бы не был столь категоричен. Всё-таки не 
настолько радикально язык изменился за эти полгода.

-- 
  Alexey "Ktirf" Rusakov

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

[Andrey Orlov]

On Tuesday 15 March 2005 02:12, Dmitry V. Levin wrote:
> On Mon, Mar 14, 2005 at 11:43:48PM +0300, Andrey Orlov wrote:
> > > По моему, это нереально.  Речь идёт о примерно 73 исходных пакетах.
> > > Думаю, будет лучше, если через несколько дней всё, что не соберут
> > > сознательные мантейнеры, пересоберёт робот.
> > 
> > Согласен. Но дадим им пару недель, ОК?
> 
> В любом случае пакеты, собранные более полугода назад, автоматической
> пересборке подвергать не имеет смысла.

Резюме: через две недели (29 марта) мы подвергаем автоматической пересборке не пересобранные
пакеты, но только те из них, которые собирались менее полугода (т.е. посл 29 сентября) назад.
Остальные пакеты отправляем в orphaned. Кстати, я уже вижу несколько кандидатур....

Если моя помощь  в деле автоматизации этого процесса что-то решает, то я готов ее оказать.

-- 
WthBstRgrds --
 -- Andrey Orlov --

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

[Dmitry V. Levin]

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

On Tue, Mar 15, 2005 at 02:22:52AM +0300, Andrey Orlov wrote:
> On Tuesday 15 March 2005 02:12, Dmitry V. Levin wrote:
> > On Mon, Mar 14, 2005 at 11:43:48PM +0300, Andrey Orlov wrote:
> > > > По моему, это нереально.  Речь идёт о примерно 73 исходных пакетах.
> > > > Думаю, будет лучше, если через несколько дней всё, что не соберут
> > > > сознательные мантейнеры, пересоберёт робот.
> > > 
> > > Согласен. Но дадим им пару недель, ОК?
> > 
> > В любом случае пакеты, собранные более полугода назад, автоматической
> > пересборке подвергать не имеет смысла.
> 
> Резюме: через две недели (29 марта) мы подвергаем автоматической пересборке не пересобранные
> пакеты, но только те из них, которые собирались менее полугода (т.е. посл 29 сентября) назад.

Чтобы период "полгода" не выглядел совсем уж взятым с потолка, пусть это
будет не 29 сентября, а "16 Sep 2004 13:41:49 +0400" - дата выпуска коробки M24.

> Остальные пакеты отправляем в orphaned. Кстати, я уже вижу несколько кандидатур....

Те, которые не соберутся, отправим туда же.

> Если моя помощь в деле автоматизации этого процесса что-то решает, то я готов ее оказать.

Если уж под cxx пересобрали (а там порой сборочная зависимость на
gcc3.3-c++ была забита прямо в spec-файлы), то здесь тем более пересоберём.

Пара достаточно регулярных выражений, и ваш spec-файл станет белым и
пушистым. :)


-- 
ldv

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

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

[Andrey Orlov]

On Tuesday 15 March 2005 02:40, Dmitry V. Levin wrote:
> Пара достаточно регулярных выражений, и ваш spec-файл станет белым и
> пушистым. :)

Такой подход мне не нравится. Оба предложенных до того нравились больше :)

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Dmitry V. Levin]

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

Hi,

On Tue, Mar 15, 2005 at 02:40:20AM +0300, Dmitry V. Levin wrote:
> On Tue, Mar 15, 2005 at 02:22:52AM +0300, Andrey Orlov wrote:
> > On Tuesday 15 March 2005 02:12, Dmitry V. Levin wrote:
> > > On Mon, Mar 14, 2005 at 11:43:48PM +0300, Andrey Orlov wrote:
> > > > > По моему, это нереально.  Речь идёт о примерно 73 исходных пакетах.
> > > > > Думаю, будет лучше, если через несколько дней всё, что не соберут
> > > > > сознательные мантейнеры, пересоберёт робот.
> > > > 
> > > > Согласен. Но дадим им пару недель, ОК?
> > > 
> > > В любом случае пакеты, собранные более полугода назад, автоматической
> > > пересборке подвергать не имеет смысла.
> > 
> > Резюме: через две недели (29 марта) мы подвергаем автоматической пересборке не пересобранные
> > пакеты, но только те из них, которые собирались менее полугода (т.е. посл 29 сентября) назад.
> 
> Чтобы период "полгода" не выглядел совсем уж взятым с потолка, пусть это
> будет не 29 сентября, а "16 Sep 2004 13:41:49 +0400" - дата выпуска коробки M24.
> 
> > Остальные пакеты отправляем в orphaned. Кстати, я уже вижу несколько кандидатур....
> 
> Те, которые не соберутся, отправим туда же.

Следующие пакеты под автопересборку не подпадают и, стало быть, претендуют
на то, чтобы уйти в orphaned:

May 18  2004 CMF-1.4.4-alt1.src.rpm
May 25  2004 ExternalEditor-0.7-alt2.src.rpm
Jul  3  2004 FloodGuard-1.1.0-alt7.src.rpm
Jul 15  2004 gnome-bluetooth-0.5.1-alt1.2.src.rpm
Aug 25  2004 IceWMCP-3.2-alt1.src.rpm
Jun 21  2004 mftrace-1.0.33-alt1.src.rpm
May 25  2004 NauDoc-2.8.3-alt2.src.rpm
May 25  2004 NuxUserGroups-0.7-alt6.src.rpm
May 25  2004 Photo-1.2.3-alt8.src.rpm
Jul 13  2004 pysol-4.82-alt4.src.rpm
Aug  7  2004 python-ClientCookie-0.4.19-alt0.1.src.rpm
Aug  7  2004 python-ClientForm-0.1.16-alt1.src.rpm
Sep 10  2004 python-module-eunuchs-0.0.0.20040910-alt1.src.rpm
Jul  3  2004 python-module-pexpect-0.999-alt7.src.rpm
May 21  2004 python-module-pyflowtools-0.3-alt4.src.rpm
May 18  2004 python-module-pyparsing-1.1.2-alt5.src.rpm
Aug 25  2004 python-module-pysnmp-3.4.2-alt1.src.rpm
Aug 31  2004 python-module-pyXLWriter-0.4-alt1.a3.src.rpm
Aug 31  2004 python-module-pyXLWriter2-2.0-alt1.a1.src.rpm
Aug 23  2004 python-module-xmms-2.03-alt1.src.rpm
Jul 15  2004 rubrica-1.0.12-alt1.1.src.rpm
Jun  1  2004 sgmltools-lite-3.0.3-alt5.1.src.rpm
Jul  6  2004 vegastrike-data-0.4.1-alt1.src.rpm
Mar 26  2004 wxPython-doc-2.4.2.4-alt1.src.rpm
Jun  5  2004 xemacs-python-modes-1.06-alt1.src.rpm


-- 
ldv

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

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

[Вячеслав Диконов]

В Втр, 29/03/2005 в 20:19 +0400, Dmitry V. Levin пишет:
> Следующие пакеты под автопересборку не подпадают и, стало быть, претендуют
> на то, чтобы уйти в orphaned:
> 

> Jul 15  2004 gnome-bluetooth-0.5.1-alt1.2.src.rpm
Категорически против. Это единственный работающий способ закачки файлов
в Siemens S55. Согласен взять себе, если никто не поддержит (и смогу
собрать).

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

[Ivan Fedorov]

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

Dmitry V. Levin пишет:
>>>>В любом случае пакеты, собранные более полугода назад, автоматической
>>>>пересборке подвергать не имеет смысла.
>>>
>>>Резюме: через две недели (29 марта) мы подвергаем автоматической пересборке не пересобранные
>>>пакеты, но только те из них, которые собирались менее полугода (т.е. посл 29 сентября) назад.
>>
>>Чтобы период "полгода" не выглядел совсем уж взятым с потолка, пусть это
>>будет не 29 сентября, а "16 Sep 2004 13:41:49 +0400" - дата выпуска коробки M24.
>>
>>
>>>Остальные пакеты отправляем в orphaned. Кстати, я уже вижу несколько кандидатур....
>>
>>Те, которые не соберутся, отправим туда же.
> 
> 
> Следующие пакеты под автопересборку не подпадают и, стало быть, претендуют
> на то, чтобы уйти в orphaned:
> 
> May 18  2004 python-module-pyparsing-1.1.2-alt5.src.rpm

Ежели хозяин не соберет, то я выложу новую версию.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Vitaly Lipatov]

On Tuesday 29 March 2005 20:19, Dmitry V. Levin wrote:
> Следующие пакеты под автопересборку не подпадают и, стало
> быть, претендуют на то, чтобы уйти в orphaned:
>
> Mar 26  2004 wxPython-doc-2.4.2.4-alt1.src.rpm
Забираю, похоже.

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

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

[Dmitry V. Levin]

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

Hi,

On Tue, Mar 15, 2005 at 02:40:20AM +0300, Dmitry V. Levin wrote:
> On Tue, Mar 15, 2005 at 02:22:52AM +0300, Andrey Orlov wrote:
> > On Tuesday 15 March 2005 02:12, Dmitry V. Levin wrote:
> > > On Mon, Mar 14, 2005 at 11:43:48PM +0300, Andrey Orlov wrote:
> > > > > По моему, это нереально.  Речь идёт о примерно 73 исходных пакетах.
> > > > > Думаю, будет лучше, если через несколько дней всё, что не соберут
> > > > > сознательные мантейнеры, пересоберёт робот.
> > > > 
> > > > Согласен. Но дадим им пару недель, ОК?
> > > 
> > > В любом случае пакеты, собранные более полугода назад, автоматической
> > > пересборке подвергать не имеет смысла.
> > 
> > Резюме: через две недели (29 марта) мы подвергаем автоматической пересборке не пересобранные
> > пакеты, но только те из них, которые собирались менее полугода (т.е. посл 29 сентября) назад.
> 
> Чтобы период "полгода" не выглядел совсем уж взятым с потолка, пусть это
> будет не 29 сентября, а "16 Sep 2004 13:41:49 +0400" - дата выпуска коробки M24.
> 
> > Остальные пакеты отправляем в orphaned. Кстати, я уже вижу несколько кандидатур....
> 
> Те, которые не соберутся, отправим туда же.

Следующие пакеты не пересобираются с новой версией python:
boson-0.10-alt3
hk_classes-0.7.2-alt1.1
superkaramba-0.35-alt1

Cборка этих пакетов завершается с красноречивыми ошибками на стадиях
%build/%install.

Таким образом, эти три пакета присоединяются к группе устаревающих.


-- 
ldv

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

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

[Sergey V Turchin]

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

В сообщении от Wednesday 30 March 2005 14:57 Dmitry V. Levin 
написал(a):

[...]

> boson-0.10-alt3
Я после выкладывания kde-3.4 пересоберу.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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