[devel] alternatives && postfix

[devel] alternatives && postfix

[Grigory Milev]

   Вопрос уже поднимался, но, что-то без результат но!!!
Собственно речь идет о сборке postfix с sasl2. Для этого в Sisyphus есть все,
кроме желания по дефолту иметь postfix собранный с вышеуказанной
библиотекой. Отсутствие собранного с ней postfix сильно подкашивает возможность
его использования как серверной почтовой программы, а так же как программы для
отсылки почты через smtp сервера с авторизацией.
  Собственно есть предложение собрать postfix-sasl или что-то подобное и
переключать его через альтернативы. Единственное но, как через альтернативы
переключать /etc/chroot.d/postfix.lib и, кто этим займется?

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

[devel] alternatives && postfix

[Grigory Milev]

   Вопрос уже поднимался, но, что-то без результат но!!!
Собственно речь идет о сборке postfix с sasl2. Для этого в Sisyphus есть все,
кроме желания по дефолту иметь postfix собранный с вышеуказанной
библиотекой. Отсутствие собранного с ней postfix сильно подкашивает возможность
его использования как серверной почтовой программы, а так же как программы для
отсылки почты через smtp сервера с авторизацией.
  Собственно есть предложение собрать postfix-sasl или что-то подобное и
переключать его через альтернативы. Единственное но, как через альтернативы
переключать /etc/chroot.d/postfix.lib и, кто этим займется?

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

Re: [devel] alternatives && postfix

[Алексей Любимов]

Grigory Milev пишет:

>   Вопрос уже поднимался, но, что-то без результат но!!!
>Собственно речь идет о сборке postfix с sasl2. Для этого в Sisyphus есть все,
>кроме желания по дефолту иметь postfix собранный с вышеуказанной
>библиотекой. Отсутствие собранного с ней postfix сильно подкашивает возможность
>его использования как серверной почтовой программы, а так же как программы для
>отсылки почты через smtp сервера с авторизацией.
>
сизиф и "серверная почтовая программа"?
Это серьезно?

>  Собственно есть предложение собрать postfix-sasl или что-то подобное и
>переключать его через альтернативы. Единственное но, как через альтернативы
>переключать /etc/chroot.d/postfix.lib и, кто этим займется?
>
а зачем тут альтернативы? в самом постфиксе есть механизм транспортов.

ps
в репозитариях linux-os.ru лежат сборки постфикса с sasl2 и mysql и 
courier-imap для мастера и сизифа.

Re: [devel] alternatives && postfix

[Алексей Любимов]

Grigory Milev пишет:

>   Вопрос уже поднимался, но, что-то без результат но!!!
>Собственно речь идет о сборке postfix с sasl2. Для этого в Sisyphus есть все,
>кроме желания по дефолту иметь postfix собранный с вышеуказанной
>библиотекой. Отсутствие собранного с ней postfix сильно подкашивает возможность
>его использования как серверной почтовой программы, а так же как программы для
>отсылки почты через smtp сервера с авторизацией.
>
сизиф и "серверная почтовая программа"?
Это серьезно?

>  Собственно есть предложение собрать postfix-sasl или что-то подобное и
>переключать его через альтернативы. Единственное но, как через альтернативы
>переключать /etc/chroot.d/postfix.lib и, кто этим займется?
>
а зачем тут альтернативы? в самом постфиксе есть механизм транспортов.

ps
в репозитариях linux-os.ru лежат сборки постфикса с sasl2 и mysql и 
courier-imap для мастера и сизифа.

[devel] Re: alternatives && postfix

[Michael Shigorin]

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

On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
> сизиф и "серверная почтовая программа"?  Это серьезно?

Это серьезнее, чем:

> ps в репозитариях linux-os.ru лежат сборки постфикса с sasl2 и
> mysql и courier-imap для мастера и сизифа.

по очевидной причине: сизиф когда-нибудь да становится блинами.

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

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

[devel] Re: alternatives && postfix

[Michael Shigorin]

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

On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
> сизиф и "серверная почтовая программа"?  Это серьезно?

Это серьезнее, чем:

> ps в репозитариях linux-os.ru лежат сборки постфикса с sasl2 и
> mysql и courier-imap для мастера и сизифа.

по очевидной причине: сизиф когда-нибудь да становится блинами.

-- 
 ---- 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: alternatives && postfix

[Алексей Любимов]

Michael Shigorin пишет:

>On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
>  
>
>>сизиф и "серверная почтовая программа"?  Это серьезно?
>>    
>>
>
>Это серьезнее, чем:
>  
>
не думаю.
только сегодня пересобрал pygtk2. в сизифе он оказался нерабочий...
тоже самое есть и будет с любой программой в сизифе.
Любые не майнстримовые сборки/конфигурации надо отлаживать в сборке, 
отлаживать в использовании и накапливать.
В сизифе есть только первая компонента. Все остальное отсутствует напрочь.

На мастерах же можно  и собирать и накапливать и использовать. Но где в 
альтлинуксе есть накопитель сделанного?

>>ps в репозитариях linux-os.ru лежат сборки постфикса с sasl2 и
>>mysql и courier-imap для мастера и сизифа.
>>    
>>
>
>по очевидной причине: сизиф когда-нибудь да становится блинами.
>  
>
Не становится. На основе собираемости софта говорить о его готовности 
нельзя.

Re: [devel] Re: alternatives && postfix

[Алексей Любимов]

Michael Shigorin пишет:

>On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
>  
>
>>сизиф и "серверная почтовая программа"?  Это серьезно?
>>    
>>
>
>Это серьезнее, чем:
>  
>
не думаю.
только сегодня пересобрал pygtk2. в сизифе он оказался нерабочий...
тоже самое есть и будет с любой программой в сизифе.
Любые не майнстримовые сборки/конфигурации надо отлаживать в сборке, 
отлаживать в использовании и накапливать.
В сизифе есть только первая компонента. Все остальное отсутствует напрочь.

На мастерах же можно  и собирать и накапливать и использовать. Но где в 
альтлинуксе есть накопитель сделанного?

>>ps в репозитариях linux-os.ru лежат сборки постфикса с sasl2 и
>>mysql и courier-imap для мастера и сизифа.
>>    
>>
>
>по очевидной причине: сизиф когда-нибудь да становится блинами.
>  
>
Не становится. На основе собираемости софта говорить о его готовности 
нельзя.

Re: [devel] Re: alternatives && postfix

[Yuri N. Sedunov]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 524 bytes --]

On 9 Февраль 2004 17:45, Алексей Любимов wrote:
> Michael Shigorin пишет:
> >On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
> >>сизиф и "серверная почтовая программа"?  Это серьезно?
> >
> >Это серьезнее, чем:
>
> не думаю.
> только сегодня пересобрал pygtk2. 

Почему нет багрепорта на pygtk2?
Где лежит?
2oes: не могли бы Вы сравнить свою сборку и avl и сообщить, действительно ли 
это так.

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

-- 
Yuri N. Sedunov

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

Re: [devel] Re: alternatives && postfix

[Yuri N. Sedunov]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 524 bytes --]

On 9 Февраль 2004 17:45, Алексей Любимов wrote:
> Michael Shigorin пишет:
> >On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
> >>сизиф и "серверная почтовая программа"?  Это серьезно?
> >
> >Это серьезнее, чем:
>
> не думаю.
> только сегодня пересобрал pygtk2. 

Почему нет багрепорта на pygtk2?
Где лежит?
2oes: не могли бы Вы сравнить свою сборку и avl и сообщить, действительно ли 
это так.

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

-- 
Yuri N. Sedunov

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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Mon, Feb 09, 2004 at 05:45:43PM +0300, Алексей Любимов wrote:
> только сегодня пересобрал pygtk2. в сизифе он оказался нерабочий...
Он оказался нерабочий для python2.3.
Для python2.2 он есть, и чУдно работает. Верьте мне (делая страшные
глаза: а то скриншотами кидаться начну).

BTW, в данный момент в сизифе есть некоторое количество питоньих
модулей, которые НЕ РАБОТАЮТ c /usr/bin/python (по очевидным причинам:
/usr/bin/python теперь, как правило, кажет на python2.3, а мэйнтэйнеры
пакетов еще их не пересобрали).

2Андрей Орлов: конструктив: давайте все-таки именовать питоньи модуля
по принципу python<version>-<modulename>. Люди меньше вопросов будут
задавать.

Вопрос, держать ли в репозитории одновременно больше одного
питона лично для меня остается открытым. На данный момент разработка у
меня ведется на python23 (и обратно на 22 мне НЕ хочется). С другой
стороны, я понимаю, что с течением времени мне захочется поставить себе
python24, но в ТО ЖЕ ВРЕМЯ, я объективно понимаю, что если написанное
нами сейчас заживет так, как это планируется в настоящий момент, мне
ПРИДЕТСЯ иметь на машине два питона. Или иметь две машины. Чрут делу НЕ
поможет. Поэтому хотелось бы, чтобы возможность бесконфликтного
существования двух питонов и модулей к ним оставалась и дальше.

> тоже самое есть и будет с любой программой в сизифе.
Ничто не вечно под луной. 

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

> На мастерах же можно  и собирать и накапливать и использовать. Но где в 
> альтлинуксе есть накопитель сделанного?
Даешь VCS для спеков и патчей?


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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Mon, Feb 09, 2004 at 05:45:43PM +0300, Алексей Любимов wrote:
> только сегодня пересобрал pygtk2. в сизифе он оказался нерабочий...
Он оказался нерабочий для python2.3.
Для python2.2 он есть, и чУдно работает. Верьте мне (делая страшные
глаза: а то скриншотами кидаться начну).

BTW, в данный момент в сизифе есть некоторое количество питоньих
модулей, которые НЕ РАБОТАЮТ c /usr/bin/python (по очевидным причинам:
/usr/bin/python теперь, как правило, кажет на python2.3, а мэйнтэйнеры
пакетов еще их не пересобрали).

2Андрей Орлов: конструктив: давайте все-таки именовать питоньи модуля
по принципу python<version>-<modulename>. Люди меньше вопросов будут
задавать.

Вопрос, держать ли в репозитории одновременно больше одного
питона лично для меня остается открытым. На данный момент разработка у
меня ведется на python23 (и обратно на 22 мне НЕ хочется). С другой
стороны, я понимаю, что с течением времени мне захочется поставить себе
python24, но в ТО ЖЕ ВРЕМЯ, я объективно понимаю, что если написанное
нами сейчас заживет так, как это планируется в настоящий момент, мне
ПРИДЕТСЯ иметь на машине два питона. Или иметь две машины. Чрут делу НЕ
поможет. Поэтому хотелось бы, чтобы возможность бесконфликтного
существования двух питонов и модулей к ним оставалась и дальше.

> тоже самое есть и будет с любой программой в сизифе.
Ничто не вечно под луной. 

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

> На мастерах же можно  и собирать и накапливать и использовать. Но где в 
> альтлинуксе есть накопитель сделанного?
Даешь VCS для спеков и патчей?


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

Re: [devel] Re: alternatives && postfix

[Alex Murygin]

On Mon, 9 Feb 2004 21:09:53 +0600
"Alexey Morozov" wrote:

> > На мастерах же можно  и собирать и накапливать и использовать. Но
> > где в альтлинуксе есть накопитель сделанного?
> Даешь CVS для спеков и патчей?
Даешь Даешь Даешь :)
И рассылку.

P.S. пожааалуйста :)

-- 
-----------------------
- Alex Murygin, AITOC -
-----------------------

Re: [devel] Re: alternatives && postfix

[Alex Murygin]

On Mon, 9 Feb 2004 21:09:53 +0600
"Alexey Morozov" wrote:

> > На мастерах же можно  и собирать и накапливать и использовать. Но
> > где в альтлинуксе есть накопитель сделанного?
> Даешь CVS для спеков и патчей?
Даешь Даешь Даешь :)
И рассылку.

P.S. пожааалуйста :)

-- 
-----------------------
- Alex Murygin, AITOC -
-----------------------

Re: [devel] Re: alternatives && postfix

[Алексей Любимов]

Yuri N. Sedunov пишет:

>On 9 Февраль 2004 17:45, Алексей Любимов wrote:
>  
>
>>Michael Shigorin пишет:
>>    
>>
>>>On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
>>>      
>>>
>>>>сизиф и "серверная почтовая программа"?  Это серьезно?
>>>>        
>>>>
>>>Это серьезнее, чем:
>>>      
>>>
>>не думаю.
>>только сегодня пересобрал pygtk2. 
>>    
>>
>
>Почему нет багрепорта на pygtk2?
>
потому что сегодня и до конца не разобрался, что конкретно не пашет.
на оджной машине работает, а на другой уже нет.

>Где лежит?
>
как всегда, на ftp.atmsk.ru/pub/distributions/...

но его еще надо распилить на pygtk2 и pygtk2-examples. мне совершенно не 
нравится текущая раскладка файлов.

Re: [devel] Re: alternatives && postfix

[Алексей Любимов]

Yuri N. Sedunov пишет:

>On 9 Февраль 2004 17:45, Алексей Любимов wrote:
>  
>
>>Michael Shigorin пишет:
>>    
>>
>>>On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
>>>      
>>>
>>>>сизиф и "серверная почтовая программа"?  Это серьезно?
>>>>        
>>>>
>>>Это серьезнее, чем:
>>>      
>>>
>>не думаю.
>>только сегодня пересобрал pygtk2. 
>>    
>>
>
>Почему нет багрепорта на pygtk2?
>
потому что сегодня и до конца не разобрался, что конкретно не пашет.
на оджной машине работает, а на другой уже нет.

>Где лежит?
>
как всегда, на ftp.atmsk.ru/pub/distributions/...

но его еще надо распилить на pygtk2 и pygtk2-examples. мне совершенно не 
нравится текущая раскладка файлов.

Re: [devel] alternatives && postfix

[Grigory Milev]

>>>>> "avl" == avl  <avl@l14.ru> writes:
    avl> сизиф и "серверная почтовая программа"?  Это серьезно?
А почему бы и нет? Если мне на серваке нужен ограниченный набор пакетов и
отследить их изменения я в силах?

    >> Собственно есть предложение собрать postfix-sasl или что-то подобное и
    >> переключать его через альтернативы. Единственное но, как через
    >> альтернативы переключать /etc/chroot.d/postfix.lib и, кто этим
    >> займется?
    >> 
    avl> а зачем тут альтернативы? в самом постфиксе есть механизм
    avl> транспортов.
Это все замечательно, но при связывании postfix + cyrus-sasl + courier-imap +
postgresql возникает необходимость авторизации smtp пользователей через sasl,
а sasl в свою очередь через pam. Кроме того, если не собрать postfix с sasl,
то postfix и сам не сможет авторизоваться по smtp, что еще более важно,
т.к. задача клиентская и она должна решаться на Сизифе.

    avl> ps в репозитариях linux-os.ru лежат сборки постфикса с sasl2 и mysql
    avl> и courier-imap для мастера и сизифа.
Это здорово и для себя я то-же сам пересобрал postfix и pam-pgsql собрал, но
это не повод для радости. Я бы предпочел иметь возможность использовать все
то-же, но из Сизифа. Мы на то его и держим, что бы иметь все необходимое под
рукой и в лучшем виде, а не таскать со всего мира кусками!!!

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

Re: [devel] alternatives && postfix

[Grigory Milev]

>>>>> "avl" == avl  <avl@l14.ru> writes:
    avl> сизиф и "серверная почтовая программа"?  Это серьезно?
А почему бы и нет? Если мне на серваке нужен ограниченный набор пакетов и
отследить их изменения я в силах?

    >> Собственно есть предложение собрать postfix-sasl или что-то подобное и
    >> переключать его через альтернативы. Единственное но, как через
    >> альтернативы переключать /etc/chroot.d/postfix.lib и, кто этим
    >> займется?
    >> 
    avl> а зачем тут альтернативы? в самом постфиксе есть механизм
    avl> транспортов.
Это все замечательно, но при связывании postfix + cyrus-sasl + courier-imap +
postgresql возникает необходимость авторизации smtp пользователей через sasl,
а sasl в свою очередь через pam. Кроме того, если не собрать postfix с sasl,
то postfix и сам не сможет авторизоваться по smtp, что еще более важно,
т.к. задача клиентская и она должна решаться на Сизифе.

    avl> ps в репозитариях linux-os.ru лежат сборки постфикса с sasl2 и mysql
    avl> и courier-imap для мастера и сизифа.
Это здорово и для себя я то-же сам пересобрал postfix и pam-pgsql собрал, но
это не повод для радости. Я бы предпочел иметь возможность использовать все
то-же, но из Сизифа. Мы на то его и держим, что бы иметь все необходимое под
рукой и в лучшем виде, а не таскать со всего мира кусками!!!

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

Re: [devel] Re: alternatives && postfix

[Алексей Любимов]

Alexey Morozov пишет:

>On Mon, Feb 09, 2004 at 05:45:43PM +0300, Алексей Любимов wrote:
>  
>
>>только сегодня пересобрал pygtk2. в сизифе он оказался нерабочий...
>>    
>>
>Он оказался нерабочий для python2.3.
>
который теперь основной, причем уже сколько времени...

>Для python2.2 он есть, и чУдно работает. Верьте мне (делая страшные
>глаза: а то скриншотами кидаться начну).
>

знаю, как насчет ЧУДНО. но работает

>  
>
>>тоже самое есть и будет с любой программой в сизифе.
>>    
>>
>Ничто не вечно под луной. 
>  
>
зафиксированое будет жить достаточно долго.

>>Любые не майнстримовые сборки/конфигурации надо отлаживать в сборке, 
>>отлаживать в использовании и накапливать.
>>В сизифе есть только первая компонента. Все остальное отсутствует напрочь.
>>    
>>
>Присутствует. В виде срезов, распространяемых линукс-шопом, Мишей
>Быковым и кем-там-еще.
>  
>
Эти срезы очень похожи на ходы в игре жизнь. Баги хаотично  исчезают и 
появляются на общем поле программ с 11 дисков. Смешно это называть 
накоплением или отладкой в использовании.

>>На мастерах же можно  и собирать и накапливать и использовать. Но где в 
>>альтлинуксе есть накопитель сделанного?
>>    
>>
>Даешь VCS для спеков и патчей?
>  
>
и что это реально даст, кроме очевидного удобства в текущем процессе?

речь идет о накоплении стабилного работоспособного софта, а не о гонке 
версий в сизифе.

Re: [devel] Re: alternatives && postfix

[Алексей Любимов]

Alexey Morozov пишет:

>On Mon, Feb 09, 2004 at 05:45:43PM +0300, Алексей Любимов wrote:
>  
>
>>только сегодня пересобрал pygtk2. в сизифе он оказался нерабочий...
>>    
>>
>Он оказался нерабочий для python2.3.
>
который теперь основной, причем уже сколько времени...

>Для python2.2 он есть, и чУдно работает. Верьте мне (делая страшные
>глаза: а то скриншотами кидаться начну).
>

знаю, как насчет ЧУДНО. но работает

>  
>
>>тоже самое есть и будет с любой программой в сизифе.
>>    
>>
>Ничто не вечно под луной. 
>  
>
зафиксированое будет жить достаточно долго.

>>Любые не майнстримовые сборки/конфигурации надо отлаживать в сборке, 
>>отлаживать в использовании и накапливать.
>>В сизифе есть только первая компонента. Все остальное отсутствует напрочь.
>>    
>>
>Присутствует. В виде срезов, распространяемых линукс-шопом, Мишей
>Быковым и кем-там-еще.
>  
>
Эти срезы очень похожи на ходы в игре жизнь. Баги хаотично  исчезают и 
появляются на общем поле программ с 11 дисков. Смешно это называть 
накоплением или отладкой в использовании.

>>На мастерах же можно  и собирать и накапливать и использовать. Но где в 
>>альтлинуксе есть накопитель сделанного?
>>    
>>
>Даешь VCS для спеков и патчей?
>  
>
и что это реально даст, кроме очевидного удобства в текущем процессе?

речь идет о накоплении стабилного работоспособного софта, а не о гонке 
версий в сизифе.

Re: [devel] Re: alternatives && postfix

[Yuri N. Sedunov]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 803 bytes --]

On 9 Февраль 2004 18:30, Алексей Любимов wrote:
> Yuri N. Sedunov пишет:
> >On 9 Февраль 2004 17:45, Алексей Любимов wrote:
> >>Michael Shigorin пишет:
> >>>On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
> >>>>сизиф и "серверная почтовая программа"?  Это серьезно?
> >>>
> >>>Это серьезнее, чем:
> >>
> >>не думаю.
> >>только сегодня пересобрал pygtk2.
> >
> >Почему нет багрепорта на pygtk2?
>
> потому что сегодня и до конца не разобрался, что конкретно не пашет.
> на оджной машине работает, а на другой уже нет.

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


-- 
Yuri N. Sedunov

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

Re: [devel] Re: alternatives && postfix

[Yuri N. Sedunov]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 803 bytes --]

On 9 Февраль 2004 18:30, Алексей Любимов wrote:
> Yuri N. Sedunov пишет:
> >On 9 Февраль 2004 17:45, Алексей Любимов wrote:
> >>Michael Shigorin пишет:
> >>>On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
> >>>>сизиф и "серверная почтовая программа"?  Это серьезно?
> >>>
> >>>Это серьезнее, чем:
> >>
> >>не думаю.
> >>только сегодня пересобрал pygtk2.
> >
> >Почему нет багрепорта на pygtk2?
>
> потому что сегодня и до конца не разобрался, что конкретно не пашет.
> на оджной машине работает, а на другой уже нет.

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


-- 
Yuri N. Sedunov

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

Re: [devel] Re: alternatives && postfix

[Алексей Любимов]

Yuri N. Sedunov пишет:

>On 9 Февраль 2004 18:30, Алексей Любимов wrote:
>  
>
>>Yuri N. Sedunov пишет:
>>    
>>
>>>On 9 Февраль 2004 17:45, Алексей Любимов wrote:
>>>      
>>>
>>>>Michael Shigorin пишет:
>>>>        
>>>>
>>>>>On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
>>>>>          
>>>>>
>>>>>>сизиф и "серверная почтовая программа"?  Это серьезно?
>>>>>>            
>>>>>>
>>>>>Это серьезнее, чем:
>>>>>          
>>>>>
>>>>не думаю.
>>>>только сегодня пересобрал pygtk2.
>>>>        
>>>>
>>>Почему нет багрепорта на pygtk2?
>>>      
>>>
>>потому что сегодня и до конца не разобрался, что конкретно не пашет.
>>на оджной машине работает, а на другой уже нет.
>>    
>>
>
>Так зачем кричать и делать обобщения по единичному и, как оказалось, не 
>проверенному факту. Сожалею, Алексей, в Ваших сообщениях все меньше 
>конструктива, зато амбиции в полный рост. Постесняйтесь немного. Давайте 
>лучше вместе помогать Сизифу.
>
>  
>
С pygtk2 был просто пример. Для девелоперской машины нерабочий 
(неактуально собраный) pygtk2 - ерунда. Пересобрал и все дела.
Но тут говорят о каких то серверных задачах. Вот обновляем на сервере 
софт и получаем...

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Mon, Feb 09, 2004 at 05:21:14PM +0200, Alex Murygin wrote:
> > > На мастерах же можно  и собирать и накапливать и использовать. Но
> > > где в альтлинуксе есть накопитель сделанного?
> > Даешь CVS для спеков и патчей?
> Даешь Даешь Даешь :)
На самом деле, как верно заметил Алексей Турбин, нужна система более
высокого уровня, нежели cvs. Там каждый чендж сам по себе,
и догадываться о том, что несколько ченджей образуют одну и ту же
группу, приходится, э-э-э, нетривиальным образом (посмотрите на то, что
делает, н-р, cvs2cl; там есть, по-моему, места для упрощения и
оптимизации процедуры поиска групп, но додумать ее до конкретного
воплощения я толком не смог). Более того, видимо, и систем с "атомарными
коммитами", навроде svn, будет недостаточно.

Нужен ЕЩЕ более высокий уровень, с контролем непротиворечивости групп
патчей. На эту роль, насколько я понимаю, в данный момент претендует
махоткинский transvn, но я на него не смотрел толком, хоть Лёша и
зазывал неоднократно, и, видимо, штука под названием darcs
http://abridgegame.org/darcs/manual/ (по крайней мере, в её доках о
таких вещах заявлено).

Но то, что двигаться в этом направлении нужно - совершенно точно.


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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Mon, Feb 09, 2004 at 05:21:14PM +0200, Alex Murygin wrote:
> > > На мастерах же можно  и собирать и накапливать и использовать. Но
> > > где в альтлинуксе есть накопитель сделанного?
> > Даешь CVS для спеков и патчей?
> Даешь Даешь Даешь :)
На самом деле, как верно заметил Алексей Турбин, нужна система более
высокого уровня, нежели cvs. Там каждый чендж сам по себе,
и догадываться о том, что несколько ченджей образуют одну и ту же
группу, приходится, э-э-э, нетривиальным образом (посмотрите на то, что
делает, н-р, cvs2cl; там есть, по-моему, места для упрощения и
оптимизации процедуры поиска групп, но додумать ее до конкретного
воплощения я толком не смог). Более того, видимо, и систем с "атомарными
коммитами", навроде svn, будет недостаточно.

Нужен ЕЩЕ более высокий уровень, с контролем непротиворечивости групп
патчей. На эту роль, насколько я понимаю, в данный момент претендует
махоткинский transvn, но я на него не смотрел толком, хоть Лёша и
зазывал неоднократно, и, видимо, штука под названием darcs
http://abridgegame.org/darcs/manual/ (по крайней мере, в её доках о
таких вещах заявлено).

Но то, что двигаться в этом направлении нужно - совершенно точно.


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

Re: [devel] Re: alternatives && postfix

[Алексей Любимов]

Yuri N. Sedunov пишет:

>On 9 Февраль 2004 18:30, Алексей Любимов wrote:
>  
>
>>Yuri N. Sedunov пишет:
>>    
>>
>>>On 9 Февраль 2004 17:45, Алексей Любимов wrote:
>>>      
>>>
>>>>Michael Shigorin пишет:
>>>>        
>>>>
>>>>>On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
>>>>>          
>>>>>
>>>>>>сизиф и "серверная почтовая программа"?  Это серьезно?
>>>>>>            
>>>>>>
>>>>>Это серьезнее, чем:
>>>>>          
>>>>>
>>>>не думаю.
>>>>только сегодня пересобрал pygtk2.
>>>>        
>>>>
>>>Почему нет багрепорта на pygtk2?
>>>      
>>>
>>потому что сегодня и до конца не разобрался, что конкретно не пашет.
>>на оджной машине работает, а на другой уже нет.
>>    
>>
>
>Так зачем кричать и делать обобщения по единичному и, как оказалось, не 
>проверенному факту. Сожалею, Алексей, в Ваших сообщениях все меньше 
>конструктива, зато амбиции в полный рост. Постесняйтесь немного. Давайте 
>лучше вместе помогать Сизифу.
>
>  
>
С pygtk2 был просто пример. Для девелоперской машины нерабочий 
(неактуально собраный) pygtk2 - ерунда. Пересобрал и все дела.
Но тут говорят о каких то серверных задачах. Вот обновляем на сервере 
софт и получаем...

Re: [devel] Re: alternatives && postfix

[Yuri N. Sedunov]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 402 bytes --]

On 9 Февраль 2004 18:30, Алексей Любимов wrote:
> Yuri N. Sedunov пишет:
> >On 9 Февраль 2004 17:45, Алексей Любимов wrote:
<skip>
>
> как всегда, на ftp.atmsk.ru/pub/distributions/...
>
> но его еще надо распилить на pygtk2 и pygtk2-examples. мне совершенно не
> нравится текущая раскладка файлов.

Так может, Вы порешаете этот вопрос с Егором, шуму будет меньше, пользы 
больше.

-- 
Yuri N. Sedunov

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

Re: [devel] Re: alternatives && postfix

[Yuri N. Sedunov]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 402 bytes --]

On 9 Февраль 2004 18:30, Алексей Любимов wrote:
> Yuri N. Sedunov пишет:
> >On 9 Февраль 2004 17:45, Алексей Любимов wrote:
<skip>
>
> как всегда, на ftp.atmsk.ru/pub/distributions/...
>
> но его еще надо распилить на pygtk2 и pygtk2-examples. мне совершенно не
> нравится текущая раскладка файлов.

Так может, Вы порешаете этот вопрос с Егором, шуму будет меньше, пользы 
больше.

-- 
Yuri N. Sedunov

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

Re: [devel] Re: alternatives && postfix

[Alexander Bokovoy]

On Mon, Feb 09, 2004 at 06:53:28PM +0300, Алексей Любимов wrote:
> >Так зачем кричать и делать обобщения по единичному и, как оказалось, не 
> >проверенному факту. Сожалею, Алексей, в Ваших сообщениях все меньше 
> >конструктива, зато амбиции в полный рост. Постесняйтесь немного. Давайте 
> >лучше вместе помогать Сизифу.
> >
> > 
> >
> С pygtk2 был просто пример. Для девелоперской машины нерабочий 
> (неактуально собраный) pygtk2 - ерунда. Пересобрал и все дела.
> Но тут говорят о каких то серверных задачах. Вот обновляем на сервере 
> софт и получаем...
Алексей, я пока наблюдаю нарастающий флейм с Вашей стороны вместо реального 
обсуждения и исправления проблемы (если таковая есть). Безосновательные
"если" совсем не в русле devel@. Давайте займемся реальными делами, а не
попытками обвинять непонятно кого в непонятно чем.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] Re: alternatives && postfix

[Alexander Bokovoy]

On Mon, Feb 09, 2004 at 06:53:28PM +0300, Алексей Любимов wrote:
> >Так зачем кричать и делать обобщения по единичному и, как оказалось, не 
> >проверенному факту. Сожалею, Алексей, в Ваших сообщениях все меньше 
> >конструктива, зато амбиции в полный рост. Постесняйтесь немного. Давайте 
> >лучше вместе помогать Сизифу.
> >
> > 
> >
> С pygtk2 был просто пример. Для девелоперской машины нерабочий 
> (неактуально собраный) pygtk2 - ерунда. Пересобрал и все дела.
> Но тут говорят о каких то серверных задачах. Вот обновляем на сервере 
> софт и получаем...
Алексей, я пока наблюдаю нарастающий флейм с Вашей стороны вместо реального 
обсуждения и исправления проблемы (если таковая есть). Безосновательные
"если" совсем не в русле devel@. Давайте займемся реальными делами, а не
попытками обвинять непонятно кого в непонятно чем.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] Re: alternatives && postfix

[Алексей Любимов]

Alexander Bokovoy пишет:

>On Mon, Feb 09, 2004 at 06:53:28PM +0300, Алексей Любимов wrote:
>  
>
>>>Так зачем кричать и делать обобщения по единичному и, как оказалось, не 
>>>проверенному факту. Сожалею, Алексей, в Ваших сообщениях все меньше 
>>>конструктива, зато амбиции в полный рост. Постесняйтесь немного. Давайте 
>>>лучше вместе помогать Сизифу.
>>>
>>>
>>>
>>>      
>>>
>>С pygtk2 был просто пример. Для девелоперской машины нерабочий 
>>(неактуально собраный) pygtk2 - ерунда. Пересобрал и все дела.
>>Но тут говорят о каких то серверных задачах. Вот обновляем на сервере 
>>софт и получаем...
>>    
>>
>Алексей, я пока наблюдаю нарастающий флейм с Вашей стороны вместо реального 
>обсуждения и исправления проблемы (если таковая есть). Безосновательные
>"если" совсем не в русле devel@. Давайте займемся реальными делами, а не
>попытками обвинять непонятно кого в непонятно чем.
>
согласен, умолкаю.

Re: [devel] Re: alternatives && postfix

[Алексей Любимов]

Alexander Bokovoy пишет:

>On Mon, Feb 09, 2004 at 06:53:28PM +0300, Алексей Любимов wrote:
>  
>
>>>Так зачем кричать и делать обобщения по единичному и, как оказалось, не 
>>>проверенному факту. Сожалею, Алексей, в Ваших сообщениях все меньше 
>>>конструктива, зато амбиции в полный рост. Постесняйтесь немного. Давайте 
>>>лучше вместе помогать Сизифу.
>>>
>>>
>>>
>>>      
>>>
>>С pygtk2 был просто пример. Для девелоперской машины нерабочий 
>>(неактуально собраный) pygtk2 - ерунда. Пересобрал и все дела.
>>Но тут говорят о каких то серверных задачах. Вот обновляем на сервере 
>>софт и получаем...
>>    
>>
>Алексей, я пока наблюдаю нарастающий флейм с Вашей стороны вместо реального 
>обсуждения и исправления проблемы (если таковая есть). Безосновательные
>"если" совсем не в русле devel@. Давайте займемся реальными делами, а не
>попытками обвинять непонятно кого в непонятно чем.
>
согласен, умолкаю.

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Mon, Feb 09, 2004 at 06:39:58PM +0300, Алексей Любимов wrote:
> >Присутствует. В виде срезов, распространяемых линукс-шопом, Мишей
> >Быковым и кем-там-еще.
> Эти срезы очень похожи на ходы в игре жизнь. Баги хаотично  исчезают и 
> появляются на общем поле программ с 11 дисков. Смешно это называть 
> накоплением или отладкой в использовании.
Да, хорошее сравнение.

> >>На мастерах же можно  и собирать и накапливать и использовать. Но где в 
> >>альтлинуксе есть накопитель сделанного?
> >Даешь VCS для спеков и патчей?
> и что это реально даст, кроме очевидного удобства в текущем процессе?
Если под VCS НЕ подразумевать CVS, а нечто более высокоуровневое, что
позволило бы набирать срезы, фактически, автоматически. В особенности,
если эта среда будет не просто свалкой спеков, а еще и свалкой с
контролем.

> речь идет о накоплении стабилного работоспособного софта, а не о гонке 
> версий в сизифе.
Алексей, боюсь, "это наша Родина, сынок". То есть, нынешняя ситуация
вызвана, во многом, принятой в опенсорс практикой: бинарной
совместимости никто не обещал, и специально этим заморачиваться не
будет. Ну, как же, всегда же можно пересобрать требуемую тебе софтину с
новым набором библиотек! Зато смотрите, как девелопмент ускоряется!

Доктрина эта, может, и хороша для Линуса, фрибздшников и прочих
гентуеров, но как только речь заходит о пакетном репозитории
внушительных размеров и множестве (удаленных) разработчиков, то тут и
начинаются тапки. Но и останавливаться на KDE-3.0 или мозилле-1.2 тоже
как-то не хочется. Что-то с этим нужно делать - совершенно точно.
Что именно - не совсем понятно.


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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Mon, Feb 09, 2004 at 06:39:58PM +0300, Алексей Любимов wrote:
> >Присутствует. В виде срезов, распространяемых линукс-шопом, Мишей
> >Быковым и кем-там-еще.
> Эти срезы очень похожи на ходы в игре жизнь. Баги хаотично  исчезают и 
> появляются на общем поле программ с 11 дисков. Смешно это называть 
> накоплением или отладкой в использовании.
Да, хорошее сравнение.

> >>На мастерах же можно  и собирать и накапливать и использовать. Но где в 
> >>альтлинуксе есть накопитель сделанного?
> >Даешь VCS для спеков и патчей?
> и что это реально даст, кроме очевидного удобства в текущем процессе?
Если под VCS НЕ подразумевать CVS, а нечто более высокоуровневое, что
позволило бы набирать срезы, фактически, автоматически. В особенности,
если эта среда будет не просто свалкой спеков, а еще и свалкой с
контролем.

> речь идет о накоплении стабилного работоспособного софта, а не о гонке 
> версий в сизифе.
Алексей, боюсь, "это наша Родина, сынок". То есть, нынешняя ситуация
вызвана, во многом, принятой в опенсорс практикой: бинарной
совместимости никто не обещал, и специально этим заморачиваться не
будет. Ну, как же, всегда же можно пересобрать требуемую тебе софтину с
новым набором библиотек! Зато смотрите, как девелопмент ускоряется!

Доктрина эта, может, и хороша для Линуса, фрибздшников и прочих
гентуеров, но как только речь заходит о пакетном репозитории
внушительных размеров и множестве (удаленных) разработчиков, то тут и
начинаются тапки. Но и останавливаться на KDE-3.0 или мозилле-1.2 тоже
как-то не хочется. Что-то с этим нужно делать - совершенно точно.
Что именно - не совсем понятно.


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

Re: [devel] alternatives && postfix

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

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

On Mon, Feb 09, 2004 at 02:47:10PM +0200, Grigory Milev wrote:

 >    Вопрос уже поднимался, но, что-то без результат но!!!
 > Собственно речь идет о сборке postfix с sasl2. Для этого в Sisyphus есть все,
 > кроме желания по дефолту иметь postfix собранный с вышеуказанной
 > библиотекой. Отсутствие собранного с ней postfix сильно подкашивает возможность
 > его использования как серверной почтовой программы, а так же как программы для
 > отсылки почты через smtp сервера с авторизацией.
 >   Собственно есть предложение собрать postfix-sasl или что-то подобное и
 > переключать его через альтернативы. Единственное но, как через альтернативы
 > переключать /etc/chroot.d/postfix.lib и, кто этим займется?

Может сделать пакет postfix-sasl, который Provides: postfix и Conflicts:
postfix ? Ситуацию установленых на одной машине _и_ postfix _и_ postfix с
sasl2 я себе слабо представляю.

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

http://freesource.info


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

Re: [devel] alternatives && postfix

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

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

On Mon, Feb 09, 2004 at 10:09:29PM +0600, Alexey Morozov wrote:

 > Доктрина эта, может, и хороша для Линуса, фрибздшников и прочих
 > гентуеров, но как только речь заходит о пакетном репозитории
 > внушительных размеров и множестве (удаленных) разработчиков, то тут и
 > начинаются тапки. Но и останавливаться на KDE-3.0 или мозилле-1.2 тоже
 > как-то не хочется. Что-то с этим нужно делать - совершенно точно.
 > Что именно - не совсем понятно.

Что-то близкой к BSD'шной схеме CURRENT/STABLE?

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

http://freesource.info


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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Monday 09 February 2004 18:09, Alexey Morozov wrote:

> 2Андрей Орлов: конструктив: давайте все-таки именовать питоньи модуля
> по принципу python<version>-<modulename>. Люди меньше вопросов будут
> задавать.

Опять 25ть. Перечитайте мои письма на эту тему и пинайте мантейнеров пакетов, 
не пересобравших свои пакеты с python23.

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

Я уже все популярно разъяснил. Все другие подходы кажутся мне:

1. Не логичными (и это самое главное);

2. Тяжело (если вообще возможно) реализуемыми;

3. Ведущими к нестабильности. 

Я уже видел редхед с тремя питонами на борту - поверте мне, это
просто жопа. 

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

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Monday 09 February 2004 18:09, Alexey Morozov wrote:

> 2Андрей Орлов: конструктив: давайте все-таки именовать питоньи модуля
> по принципу python<version>-<modulename>. Люди меньше вопросов будут
> задавать.

Опять 25ть. Перечитайте мои письма на эту тему и пинайте мантейнеров пакетов, 
не пересобравших свои пакеты с python23.

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

Я уже все популярно разъяснил. Все другие подходы кажутся мне:

1. Не логичными (и это самое главное);

2. Тяжело (если вообще возможно) реализуемыми;

3. Ведущими к нестабильности. 

Я уже видел редхед с тремя питонами на борту - поверте мне, это
просто жопа. 

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

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

[devel] Re: alternatives && postfix

[Michael Shigorin]

On Mon, Feb 09, 2004 at 09:09:33PM +0300, Andrey Orlov wrote:
> Опять 25ть. Перечитайте мои письма на эту тему и пинайте
> мантейнеров пакетов, не пересобравших свои пакеты с python23.

Мож версионирование Requires: python устрожить?

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

[devel] Re: alternatives && postfix

[Michael Shigorin]

On Mon, Feb 09, 2004 at 09:09:33PM +0300, Andrey Orlov wrote:
> Опять 25ть. Перечитайте мои письма на эту тему и пинайте
> мантейнеров пакетов, не пересобравших свои пакеты с python23.

Мож версионирование Requires: python устрожить?

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

Re: [devel] Re: alternatives && postfix

[Alexey Lubimov]

Michael Shigorin пишет:
> On Mon, Feb 09, 2004 at 09:09:33PM +0300, Andrey Orlov wrote:
> 
>>Опять 25ть. Перечитайте мои письма на эту тему и пинайте
>>мантейнеров пакетов, не пересобравших свои пакеты с python23.
> 
> 
> Мож версионирование Requires: python устрожить?
ага, я уже попытался.

Requires: python22 или Requires: python23 работают _гораздо_ хуже.

Requires: python=%{__python_version} ?

Имхо, костылики все это...

Re: [devel] Re: alternatives && postfix

[Alexey Lubimov]

Michael Shigorin пишет:
> On Mon, Feb 09, 2004 at 09:09:33PM +0300, Andrey Orlov wrote:
> 
>>Опять 25ть. Перечитайте мои письма на эту тему и пинайте
>>мантейнеров пакетов, не пересобравших свои пакеты с python23.
> 
> 
> Мож версионирование Requires: python устрожить?
ага, я уже попытался.

Requires: python22 или Requires: python23 работают _гораздо_ хуже.

Requires: python=%{__python_version} ?

Имхо, костылики все это...

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Monday 09 February 2004 21:29, Michael Shigorin wrote:
> On Mon, Feb 09, 2004 at 09:09:33PM +0300, Andrey Orlov wrote:
> > Опять 25ть. Перечитайте мои письма на эту тему и пинайте
> > мантейнеров пакетов, не пересобравших свои пакеты с python23.
>
> Мож версионирование Requires: python устрожить?

Мих, еще раз, проблема в том что его _не _пересобрали_. Причем
тут Requires? 

Кстати, я не понимаю как pygtk мог работать в python23
если был собран под python22 - он же должен был лежать 
в /usr/lib/python22/site-packages, как его python23 увидел? Как он у 
Алексея мог "не работать"? Он вообще не должен был импортироваться,
 а не "не работать"! Если python23 -c "import pygtk2"  завершался
без ошибки в этой ситуации - то это мой баг! О котором надо, блин, написать
багрепорт! А не сидеть в углу и что-то там извращать локально в /usr/local !

Все рассказы про то, что "у нас питон по  умолчанию указывает 
теперь на python23" - тут совершенно не при чем. 
Пинайте мантейнера, чбы пересобрал под python23! Я еще раз утверждаю,
__никакой__ проблемы нет. Есть просто непонимание и нежелание разбираться,
а также откровенно некорректные высказывания.


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

Re: [devel] Re: alternatives && postfix

[Egor S. Orlov]

> Где лежит?
> 2oes: не могли бы Вы сравнить свою сборку и avl и сообщить, действительно ли 
> это так.
> 

да, он нерабочий именно с python23, т.к. собран с 22

пересобирать пока не получается,
ему la-файлов от libgtk+2-devel сильно хочется

-- 
WBR, Egor S. Orlov
FST SPbSPU

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Monday 09 February 2004 21:29, Michael Shigorin wrote:
> On Mon, Feb 09, 2004 at 09:09:33PM +0300, Andrey Orlov wrote:
> > Опять 25ть. Перечитайте мои письма на эту тему и пинайте
> > мантейнеров пакетов, не пересобравших свои пакеты с python23.
>
> Мож версионирование Requires: python устрожить?

Мих, еще раз, проблема в том что его _не _пересобрали_. Причем
тут Requires? 

Кстати, я не понимаю как pygtk мог работать в python23
если был собран под python22 - он же должен был лежать 
в /usr/lib/python22/site-packages, как его python23 увидел? Как он у 
Алексея мог "не работать"? Он вообще не должен был импортироваться,
 а не "не работать"! Если python23 -c "import pygtk2"  завершался
без ошибки в этой ситуации - то это мой баг! О котором надо, блин, написать
багрепорт! А не сидеть в углу и что-то там извращать локально в /usr/local !

Все рассказы про то, что "у нас питон по  умолчанию указывает 
теперь на python23" - тут совершенно не при чем. 
Пинайте мантейнера, чбы пересобрал под python23! Я еще раз утверждаю,
__никакой__ проблемы нет. Есть просто непонимание и нежелание разбираться,
а также откровенно некорректные высказывания.


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

Re: [devel] Re: alternatives && postfix

[Egor S. Orlov]

> Где лежит?
> 2oes: не могли бы Вы сравнить свою сборку и avl и сообщить, действительно ли 
> это так.
> 

да, он нерабочий именно с python23, т.к. собран с 22

пересобирать пока не получается,
ему la-файлов от libgtk+2-devel сильно хочется

-- 
WBR, Egor S. Orlov
FST SPbSPU

[devel] Re: alternatives && postfix

[Michael Shigorin]

On Mon, Feb 09, 2004 at 10:13:05PM +0300, Andrey Orlov wrote:
> > > Опять 25ть. Перечитайте мои письма на эту тему и пинайте
> > > мантейнеров пакетов, не пересобравших свои пакеты с python23.
> > Мож версионирование Requires: python устрожить?
> Мих, еще раз, проблема в том что его _не _пересобрали_. Причем
> тут Requires? 

При "следующем разе".

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

[devel] Re: alternatives && postfix

[Michael Shigorin]

On Mon, Feb 09, 2004 at 10:13:05PM +0300, Andrey Orlov wrote:
> > > Опять 25ть. Перечитайте мои письма на эту тему и пинайте
> > > мантейнеров пакетов, не пересобравших свои пакеты с python23.
> > Мож версионирование Requires: python устрожить?
> Мих, еще раз, проблема в том что его _не _пересобрали_. Причем
> тут Requires? 

При "следующем разе".

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

Re: [devel] alternatives && postfix

[Valery V. Inozemtsev]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 341 bytes --]

<skip>
> возможный вариант, но тогда postfix-sasl должен собираться со всеми
> опциями, которые есть сейчас в postfix???

угу

>
> и как sasl2 живет с postfix в chroot'е?

у меня вот так:

/etc/sysconfig/saslauthd

OPTIONS="-a pam -m /var/spool/postfix/var/run/saslauthd"

-- 
Valery V. Inozemtsev	ftp://shrek.tenso-m.ru/pub/shrek/ALTLinux/

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

Re: [devel] Re: alternatives && postfix

[Alexey Lubimov]

Egor S. Orlov пишет:
>>Где лежит?
>>2oes: не могли бы Вы сравнить свою сборку и avl и сообщить, действительно ли 
>>это так.
>>
> 
> 
> да, он нерабочий именно с python23, т.к. собран с 22
> 
> пересобирать пока не получается,
> ему la-файлов от libgtk+2-devel сильно хочется

У меня нормально собрался и в сизиф и в мастер.
Заодно (имхо) удачно  распилил на pygtk2 pygtk2-devel и pygtk2-examples.


ftp://ftp.atmsk.ru/pub/distributions/SRPMS.sisyphus/pygtk2-2.0.0-avl11.src.rpm

Re: [devel] Re: alternatives && postfix

[Alexey Lubimov]

Egor S. Orlov пишет:
>>Где лежит?
>>2oes: не могли бы Вы сравнить свою сборку и avl и сообщить, действительно ли 
>>это так.
>>
> 
> 
> да, он нерабочий именно с python23, т.к. собран с 22
> 
> пересобирать пока не получается,
> ему la-файлов от libgtk+2-devel сильно хочется

У меня нормально собрался и в сизиф и в мастер.
Заодно (имхо) удачно  распилил на pygtk2 pygtk2-devel и pygtk2-examples.


ftp://ftp.atmsk.ru/pub/distributions/SRPMS.sisyphus/pygtk2-2.0.0-avl11.src.rpm

Re[2]: [devel] alternatives && postfix

[Volkov Serge]

Hello Денис,

Monday, February 9, 2004, 8:05:50 PM, you wrote:

ДС> On Mon, Feb 09, 2004 at 02:47:10PM +0200, Grigory Milev wrote:

ДС>  >    Вопрос уже поднимался, но, что-то без результат но!!!
ДС>  > Собственно речь идет о сборке postfix с sasl2. Для этого в Sisyphus есть все,
ДС>  > кроме желания по дефолту иметь postfix собранный с вышеуказанной
ДС>  > библиотекой. Отсутствие собранного с ней postfix сильно подкашивает возможность
ДС>  > его использования как серверной почтовой программы, а так же как программы для
ДС>  > отсылки почты через smtp сервера с авторизацией.
ДС>  >   Собственно есть предложение собрать postfix-sasl или что-то подобное и
ДС>  > переключать его через альтернативы. Единственное но, как через альтернативы
ДС>  > переключать /etc/chroot.d/postfix.lib и, кто этим займется?

ДС> Может сделать пакет postfix-sasl, который Provides: postfix и Conflicts:
ДС> postfix ? Ситуацию установленых на одной машине _и_ postfix _и_ postfix с
ДС> sasl2 я себе слабо представляю.


возможный вариант, но тогда postfix-sasl должен собираться со всеми
опциями, которые есть сейчас в postfix???

и как sasl2 живет с postfix в chroot'е?

-- 
Best regards,
 Volkov                            mailto:vserge@altlinux.ru

Re: [devel] Re: alternatives && postfix

[Alexey Lubimov]

Andrey Orlov пишет:
> On Monday 09 February 2004 21:29, Michael Shigorin wrote:
> 
>>On Mon, Feb 09, 2004 at 09:09:33PM +0300, Andrey Orlov wrote:
>>
>>>Опять 25ть. Перечитайте мои письма на эту тему и пинайте
>>>мантейнеров пакетов, не пересобравших свои пакеты с python23.
>>
>>Мож версионирование Requires: python устрожить?
> 
> 
> Мих, еще раз, проблема в том что его _не _пересобрали_. Причем
> тут Requires? 

Честно говоря, непонятна причина непересборки.
Без претензий и флейма, просто не понятно. Уже раз сто читал про чуть ли 
не ежедневную _тотальную_ пересборку всех пакетов сизифа  в 
хашере/сандмене и опять _не _пересобрали_?

Или если пакет не пересобирается, то он просто остается в том виде, как 
он был собран последний раз?

> 
> Кстати, я не понимаю как pygtk мог работать в python23
> если был собран под python22 - он же должен был лежать 
> в /usr/lib/python22/site-packages, как его python23 увидел? Как он у 
> Алексея мог "не работать"? Он вообще не должен был импортироваться,
>  а не "не работать"! 

Во первых, у меня и тот и другой питоны стоят и работают. пробовал с 
обоими. Просто какой то коленчатый вал получился. Что то с питон23 
собрано, а что то с питон22 и как не поверни - все время не работает.


Если python23 -c "import pygtk2"  завершался
> без ошибки в этой ситуации - то это мой баг! О котором надо, блин, написать
> багрепорт! А не сидеть в углу и что-то там извращать локально в /usr/local !

import gtk; g = gtk не проходил, а не import pygtk, что довольно необычно.

к тому же в *2.3/site-packages был pygtk2.

> 
> Все рассказы про то, что "у нас питон по  умолчанию указывает 
> теперь на python23" - тут совершенно не при чем. 
> Пинайте мантейнера, чбы пересобрал под python23! Я еще раз утверждаю,
> __никакой__ проблемы нет. Есть просто непонимание и нежелание разбираться,
> а также откровенно некорректные высказывания.

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

итого, пакеты устанавливаются, но не работают...

Re: [devel] Re: alternatives && postfix

[Alexey Lubimov]

Andrey Orlov пишет:
> On Monday 09 February 2004 21:29, Michael Shigorin wrote:
> 
>>On Mon, Feb 09, 2004 at 09:09:33PM +0300, Andrey Orlov wrote:
>>
>>>Опять 25ть. Перечитайте мои письма на эту тему и пинайте
>>>мантейнеров пакетов, не пересобравших свои пакеты с python23.
>>
>>Мож версионирование Requires: python устрожить?
> 
> 
> Мих, еще раз, проблема в том что его _не _пересобрали_. Причем
> тут Requires? 

Честно говоря, непонятна причина непересборки.
Без претензий и флейма, просто не понятно. Уже раз сто читал про чуть ли 
не ежедневную _тотальную_ пересборку всех пакетов сизифа  в 
хашере/сандмене и опять _не _пересобрали_?

Или если пакет не пересобирается, то он просто остается в том виде, как 
он был собран последний раз?

> 
> Кстати, я не понимаю как pygtk мог работать в python23
> если был собран под python22 - он же должен был лежать 
> в /usr/lib/python22/site-packages, как его python23 увидел? Как он у 
> Алексея мог "не работать"? Он вообще не должен был импортироваться,
>  а не "не работать"! 

Во первых, у меня и тот и другой питоны стоят и работают. пробовал с 
обоими. Просто какой то коленчатый вал получился. Что то с питон23 
собрано, а что то с питон22 и как не поверни - все время не работает.


Если python23 -c "import pygtk2"  завершался
> без ошибки в этой ситуации - то это мой баг! О котором надо, блин, написать
> багрепорт! А не сидеть в углу и что-то там извращать локально в /usr/local !

import gtk; g = gtk не проходил, а не import pygtk, что довольно необычно.

к тому же в *2.3/site-packages был pygtk2.

> 
> Все рассказы про то, что "у нас питон по  умолчанию указывает 
> теперь на python23" - тут совершенно не при чем. 
> Пинайте мантейнера, чбы пересобрал под python23! Я еще раз утверждаю,
> __никакой__ проблемы нет. Есть просто непонимание и нежелание разбираться,
> а также откровенно некорректные высказывания.

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

итого, пакеты устанавливаются, но не работают...

Re[2]: [devel] alternatives && postfix

[Volkov Serge]

Hello Денис,

Monday, February 9, 2004, 8:05:50 PM, you wrote:

ДС> On Mon, Feb 09, 2004 at 02:47:10PM +0200, Grigory Milev wrote:

ДС>  >    Вопрос уже поднимался, но, что-то без результат но!!!
ДС>  > Собственно речь идет о сборке postfix с sasl2. Для этого в Sisyphus есть все,
ДС>  > кроме желания по дефолту иметь postfix собранный с вышеуказанной
ДС>  > библиотекой. Отсутствие собранного с ней postfix сильно подкашивает возможность
ДС>  > его использования как серверной почтовой программы, а так же как программы для
ДС>  > отсылки почты через smtp сервера с авторизацией.
ДС>  >   Собственно есть предложение собрать postfix-sasl или что-то подобное и
ДС>  > переключать его через альтернативы. Единственное но, как через альтернативы
ДС>  > переключать /etc/chroot.d/postfix.lib и, кто этим займется?

ДС> Может сделать пакет postfix-sasl, который Provides: postfix и Conflicts:
ДС> postfix ? Ситуацию установленых на одной машине _и_ postfix _и_ postfix с
ДС> sasl2 я себе слабо представляю.


возможный вариант, но тогда postfix-sasl должен собираться со всеми
опциями, которые есть сейчас в postfix???

и как sasl2 живет с postfix в chroot'е?

-- 
Best regards,
 Volkov                            mailto:vserge@altlinux.ru

Re: [devel] alternatives && postfix

[Valery V. Inozemtsev]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 341 bytes --]

<skip>
> возможный вариант, но тогда postfix-sasl должен собираться со всеми
> опциями, которые есть сейчас в postfix???

угу

>
> и как sasl2 живет с postfix в chroot'е?

у меня вот так:

/etc/sysconfig/saslauthd

OPTIONS="-a pam -m /var/spool/postfix/var/run/saslauthd"

-- 
Valery V. Inozemtsev	ftp://shrek.tenso-m.ru/pub/shrek/ALTLinux/

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Monday 09 February 2004 23:23, Alexey Lubimov wrote:
> import gtk; g = gtk не проходил, а не import pygtk, что довольно необычно.
>
> к тому же в *2.3/site-packages был pygtk2.

Откуда же он у вас там взялся? Я специально слил из сизифа пакет и посмотрел
- pygtk2 ставится в 2.2/site-packages, а не в 2.3.

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

Пакеты пересобранные для разных версий _ставятся_ в  разные каталоги. 
И пакеты по зависимостям вытягивают правильные версии питона. В зависимостях
собранного пакета тоже прописана нужная версия питона, я уж не знаю, что там
с pygtk (не полезу щаз смотреть), но вот например:

rpm -q --requires python-imaging
python = 2.3
...

rpm -q --requires Zope
python = 2.3

Так чего же вы по зависимостм не можете понять кто с какой версией собран? 

Ну и наконец последний вопрос: как у вас в 2.3/site-packages оказался пакет,
который устанавливается в 2.2/site-packages ?

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

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Monday 09 February 2004 23:23, Alexey Lubimov wrote:
> import gtk; g = gtk не проходил, а не import pygtk, что довольно необычно.
>
> к тому же в *2.3/site-packages был pygtk2.

Откуда же он у вас там взялся? Я специально слил из сизифа пакет и посмотрел
- pygtk2 ставится в 2.2/site-packages, а не в 2.3.

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

Пакеты пересобранные для разных версий _ставятся_ в  разные каталоги. 
И пакеты по зависимостям вытягивают правильные версии питона. В зависимостях
собранного пакета тоже прописана нужная версия питона, я уж не знаю, что там
с pygtk (не полезу щаз смотреть), но вот например:

rpm -q --requires python-imaging
python = 2.3
...

rpm -q --requires Zope
python = 2.3

Так чего же вы по зависимостм не можете понять кто с какой версией собран? 

Ну и наконец последний вопрос: как у вас в 2.3/site-packages оказался пакет,
который устанавливается в 2.2/site-packages ?

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

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Monday 09 February 2004 22:37, Michael Shigorin wrote:
> > Мих, еще раз, проблема в том что его _не _пересобрали_. Причем
> > тут Requires?
> При "следующем разе".

Не понял. 


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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Monday 09 February 2004 22:37, Michael Shigorin wrote:
> > Мих, еще раз, проблема в том что его _не _пересобрали_. Причем
> > тут Requires?
> При "следующем разе".

Не понял. 


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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Monday 09 February 2004 23:23, Alexey Lubimov wrote:
> Во первых, у меня и тот и другой питоны стоят и работают. пробовал с
> обоими. 

Вот в этом и есть корень вашей проблемы. Солюшен такой:

1.  Сносите python22
2.  Как только какой-то из ваших или чужих пакетов затребовал его установку -
пересобираете или пишите письмо мантейнеру с просьбой пересобрать.
3.  Еще раз напоминаю, python22 - только для разработчиков. Так как
"иногда надо для опытов". В дистрибутив этот пакет скорее всего не войдет.



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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Monday 09 February 2004 23:23, Alexey Lubimov wrote:
> Во первых, у меня и тот и другой питоны стоят и работают. пробовал с
> обоими. 

Вот в этом и есть корень вашей проблемы. Солюшен такой:

1.  Сносите python22
2.  Как только какой-то из ваших или чужих пакетов затребовал его установку -
пересобираете или пишите письмо мантейнеру с просьбой пересобрать.
3.  Еще раз напоминаю, python22 - только для разработчиков. Так как
"иногда надо для опытов". В дистрибутив этот пакет скорее всего не войдет.



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

Re: [devel] Re: alternatives && postfix

[Yuri N. Sedunov]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 383 bytes --]

On 9 Февраль 2004 22:12, Egor S. Orlov wrote:
> > Где лежит?
> > 2oes: не могли бы Вы сравнить свою сборку и avl и сообщить, действительно
> > ли это так.
>
> да, он нерабочий именно с python23, т.к. собран с 22
>
> пересобирать пока не получается,
> ему la-файлов от libgtk+2-devel сильно хочется

Ну так пересоберите и gtkglarea2, чтоб убрать из него лафайлы.

-- 
Yuri N. Sedunov

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

Re: [devel] Re: alternatives && postfix

[Yuri N. Sedunov]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 383 bytes --]

On 9 Февраль 2004 22:12, Egor S. Orlov wrote:
> > Где лежит?
> > 2oes: не могли бы Вы сравнить свою сборку и avl и сообщить, действительно
> > ли это так.
>
> да, он нерабочий именно с python23, т.к. собран с 22
>
> пересобирать пока не получается,
> ему la-файлов от libgtk+2-devel сильно хочется

Ну так пересоберите и gtkglarea2, чтоб убрать из него лафайлы.

-- 
Yuri N. Sedunov

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

Re: [devel] Re: alternatives && postfix

[Alexey Lubimov]

Andrey Orlov пишет:
> On Monday 09 February 2004 23:23, Alexey Lubimov wrote:
> 
>>import gtk; g = gtk не проходил, а не import pygtk, что довольно необычно.
>>
>>к тому же в *2.3/site-packages был pygtk2.
> 
> 
> Откуда же он у вас там взялся? Я специально слил из сизифа пакет и посмотрел
> - pygtk2 ставится в 2.2/site-packages, а не в 2.3.

надо посмотреть.

>>боюсь, что нельзя требовать тотальной пересборки всех питон зависимых
>>пакетов сразу во всем мире. Нужно хотя бы знать, что эта проблема имеет
>>место быть. На текущий момент ни по зависимостям, ни по названиям
>>пакетов понять, что они не  с той версией собраны никак не получается...
>>
>>итого, пакеты устанавливаются, но не работают...
> 
> 
> Пакеты пересобранные для разных версий _ставятся_ в  разные каталоги. 
> И пакеты по зависимостям вытягивают правильные версии питона. В зависимостях
> собранного пакета тоже прописана нужная версия питона, я уж не знаю, что там
> с pygtk (не полезу щаз смотреть), но вот например:
> 
> rpm -q --requires python-imaging
> python = 2.3
> ...

rpm -qp --requires python-ctypes-0.6.3-alt.i586.rpm
python
libffi
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1.3)
libffi.so.2
libpthread.so.0


Name: python-ctypes 
         Summary: create and manipulate C data types in Python 
                  Version: 0.6.3 
                           Release: alt 
                                    Source: 
%{modulename}-%{version}.tar.gz 
Group: System/Servers/ZProducts 
         License: GPL 
                  Requires: python libffi 
                           BuildRequires: python  python-devel 
libffi-devel



Получается, таки надо ставить Requires: python = %__python_version ?

Re: [devel] Re: alternatives && postfix

[Alexey Lubimov]

Andrey Orlov пишет:
> On Monday 09 February 2004 23:23, Alexey Lubimov wrote:
> 
>>import gtk; g = gtk не проходил, а не import pygtk, что довольно необычно.
>>
>>к тому же в *2.3/site-packages был pygtk2.
> 
> 
> Откуда же он у вас там взялся? Я специально слил из сизифа пакет и посмотрел
> - pygtk2 ставится в 2.2/site-packages, а не в 2.3.

надо посмотреть.

>>боюсь, что нельзя требовать тотальной пересборки всех питон зависимых
>>пакетов сразу во всем мире. Нужно хотя бы знать, что эта проблема имеет
>>место быть. На текущий момент ни по зависимостям, ни по названиям
>>пакетов понять, что они не  с той версией собраны никак не получается...
>>
>>итого, пакеты устанавливаются, но не работают...
> 
> 
> Пакеты пересобранные для разных версий _ставятся_ в  разные каталоги. 
> И пакеты по зависимостям вытягивают правильные версии питона. В зависимостях
> собранного пакета тоже прописана нужная версия питона, я уж не знаю, что там
> с pygtk (не полезу щаз смотреть), но вот например:
> 
> rpm -q --requires python-imaging
> python = 2.3
> ...

rpm -qp --requires python-ctypes-0.6.3-alt.i586.rpm
python
libffi
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1.3)
libffi.so.2
libpthread.so.0


Name: python-ctypes 
         Summary: create and manipulate C data types in Python 
                  Version: 0.6.3 
                           Release: alt 
                                    Source: 
%{modulename}-%{version}.tar.gz 
Group: System/Servers/ZProducts 
         License: GPL 
                  Requires: python libffi 
                           BuildRequires: python  python-devel 
libffi-devel



Получается, таки надо ставить Requires: python = %__python_version ?

Re: [devel] Re: alternatives && postfix

[Alexey Lubimov]

Andrey Orlov пишет:
> On Monday 09 February 2004 23:23, Alexey Lubimov wrote:
> 
>>Во первых, у меня и тот и другой питоны стоят и работают. пробовал с
>>обоими. 
> 
> 
> Вот в этом и есть корень вашей проблемы. Солюшен такой:
> 
> 1.  Сносите python22

у меня пара серверов с зопом на питоне 2.2 крутится + несколько машин с 
мастерами/сизифами разной свежести. их поддерживать надо. Так что не 
вариант.

> 2.  Как только какой-то из ваших или чужих пакетов затребовал его установку -
> пересобираете или пишите письмо мантейнеру с просьбой пересобрать.

Процесс идет.


> 3.  Еще раз напоминаю, python22 - только для разработчиков. Так как
> "иногда надо для опытов". В дистрибутив этот пакет скорее всего не войдет.

боюсь, что такая постановка вопроса из разряда "одна libdb4X.X, один 
gcc, одно ядро etc". Здорово, но нереально...

Re: [devel] Re: alternatives && postfix

[Alexey Lubimov]

Andrey Orlov пишет:
> On Monday 09 February 2004 23:23, Alexey Lubimov wrote:
> 
>>Во первых, у меня и тот и другой питоны стоят и работают. пробовал с
>>обоими. 
> 
> 
> Вот в этом и есть корень вашей проблемы. Солюшен такой:
> 
> 1.  Сносите python22

у меня пара серверов с зопом на питоне 2.2 крутится + несколько машин с 
мастерами/сизифами разной свежести. их поддерживать надо. Так что не 
вариант.

> 2.  Как только какой-то из ваших или чужих пакетов затребовал его установку -
> пересобираете или пишите письмо мантейнеру с просьбой пересобрать.

Процесс идет.


> 3.  Еще раз напоминаю, python22 - только для разработчиков. Так как
> "иногда надо для опытов". В дистрибутив этот пакет скорее всего не войдет.

боюсь, что такая постановка вопроса из разряда "одна libdb4X.X, один 
gcc, одно ядро etc". Здорово, но нереально...

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 01:26, Alexey Lubimov wrote:
> Получается, таки надо ставить Requires: python = %__python_version ?

Похоже на то. Иначе неизвестно что ставить.

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 01:31, Alexey Lubimov wrote:
> > Вот в этом и есть корень вашей проблемы. Солюшен такой:
> >
> > 1.  Сносите python22
>
> у меня пара серверов с зопом на питоне 2.2 крутится + несколько машин с
> мастерами/сизифами разной свежести. их поддерживать надо. Так что не
> вариант.

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

Пример такого бессмысленного решения:

 zope требует c

 zope требует d

 с  требует python22

 d требует python23

 zope требует python23

 Если добавить ограничение "python23 конфликтует с python22" - то все нормально, система несовместна. Как
 только вы разрешаете стоять и тому, и другому - начинается коленвал, обойти который -
 нельзя.

 Теперь о поддержке мастера & сизифа. Я уже неоднократно говорил, что чтобы подддерживать уже
 наработанные решения под мастером держу на машине мастер. Это сильно урезанный мастер -
 в конце-концов мне в нем нужен только питон, rpm etc. Занимает <100 метров. В него
 командой mount --bind /home /var/lib/master/home смонтирован хоумник. На самом деле, все 
 немножко сложнее - но идея, я думаю, ясна:

 мастер конфликтует с сизифом - это очевидно, оба сразу стоять не могут. Так что разносим
 их и все.

 Собственно, чбы никто не удивлялся, я собираюсь прописать конфликт между python23 & python22.
 Чбы убрать коленвал, ибо надоело.

4LDV: Кроме того, я предлагаю снести в обсолетед все пакеты,  требующие  python22. За три
месяца можно было пересобрать, они явно забыты мантейнерами и никому не нужны.

> > 3.  Еще раз напоминаю, python22 - только для разработчиков. Так как
> > "иногда надо для опытов". В дистрибутив этот пакет скорее всего не
> > войдет.
>
> боюсь, что такая постановка вопроса из разряда "одна libdb4X.X, один
> gcc, одно ядро etc". Здорово, но нереально...

В  данном случае - реально. Я уже не первый раз прошу предъявить мне пакет, принципиально
не пересобираемый с python23. Так что не надо гнать.

Еще раз, для всех: тот, кто хочет разрабатывать на python22 _должен_ ставить мастер22. Тот, 
кто хочет разрабатывать на python21 - мастер 20. Тот, кто хочет разрабатывать на python1.52 -
я уж даже не помню, что он должен поставить, но никак не сизиф. 

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 01:26, Alexey Lubimov wrote:
> Получается, таки надо ставить Requires: python = %__python_version ?

Похоже на то. Иначе неизвестно что ставить.

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 01:31, Alexey Lubimov wrote:
> > Вот в этом и есть корень вашей проблемы. Солюшен такой:
> >
> > 1.  Сносите python22
>
> у меня пара серверов с зопом на питоне 2.2 крутится + несколько машин с
> мастерами/сизифами разной свежести. их поддерживать надо. Так что не
> вариант.

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

Пример такого бессмысленного решения:

 zope требует c

 zope требует d

 с  требует python22

 d требует python23

 zope требует python23

 Если добавить ограничение "python23 конфликтует с python22" - то все нормально, система несовместна. Как
 только вы разрешаете стоять и тому, и другому - начинается коленвал, обойти который -
 нельзя.

 Теперь о поддержке мастера & сизифа. Я уже неоднократно говорил, что чтобы подддерживать уже
 наработанные решения под мастером держу на машине мастер. Это сильно урезанный мастер -
 в конце-концов мне в нем нужен только питон, rpm etc. Занимает <100 метров. В него
 командой mount --bind /home /var/lib/master/home смонтирован хоумник. На самом деле, все 
 немножко сложнее - но идея, я думаю, ясна:

 мастер конфликтует с сизифом - это очевидно, оба сразу стоять не могут. Так что разносим
 их и все.

 Собственно, чбы никто не удивлялся, я собираюсь прописать конфликт между python23 & python22.
 Чбы убрать коленвал, ибо надоело.

4LDV: Кроме того, я предлагаю снести в обсолетед все пакеты,  требующие  python22. За три
месяца можно было пересобрать, они явно забыты мантейнерами и никому не нужны.

> > 3.  Еще раз напоминаю, python22 - только для разработчиков. Так как
> > "иногда надо для опытов". В дистрибутив этот пакет скорее всего не
> > войдет.
>
> боюсь, что такая постановка вопроса из разряда "одна libdb4X.X, один
> gcc, одно ядро etc". Здорово, но нереально...

В  данном случае - реально. Я уже не первый раз прошу предъявить мне пакет, принципиально
не пересобираемый с python23. Так что не надо гнать.

Еще раз, для всех: тот, кто хочет разрабатывать на python22 _должен_ ставить мастер22. Тот, 
кто хочет разрабатывать на python21 - мастер 20. Тот, кто хочет разрабатывать на python1.52 -
я уж даже не помню, что он должен поставить, но никак не сизиф. 

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

[devel] Re: alternatives && postfix

[Alexey Tourbin]

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

On Mon, Feb 09, 2004 at 10:13:05PM +0300, Andrey Orlov wrote:
> Мих, еще раз, проблема в том что его _не _пересобрали_. Причем
> тут Requires? 
> 
> Кстати, я не понимаю как pygtk мог работать в python23
> если был собран под python22 - он же должен был лежать 
> в /usr/lib/python22/site-packages, как его python23 увидел? Как он у 

Hi!

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

> Алексея мог "не работать"? Он вообще не должен был импортироваться,
>  а не "не работать"! Если python23 -c "import pygtk2"  завершался
> без ошибки в этой ситуации - то это мой баг! О котором надо, блин, написать
> багрепорт! А не сидеть в углу и что-то там извращать локально в /usr/local !

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

[devel] Re: alternatives && postfix

[Alexey Tourbin]

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

On Mon, Feb 09, 2004 at 10:13:05PM +0300, Andrey Orlov wrote:
> Мих, еще раз, проблема в том что его _не _пересобрали_. Причем
> тут Requires? 
> 
> Кстати, я не понимаю как pygtk мог работать в python23
> если был собран под python22 - он же должен был лежать 
> в /usr/lib/python22/site-packages, как его python23 увидел? Как он у 

Hi!

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

> Алексея мог "не работать"? Он вообще не должен был импортироваться,
>  а не "не работать"! Если python23 -c "import pygtk2"  завершался
> без ошибки в этой ситуации - то это мой баг! О котором надо, блин, написать
> багрепорт! А не сидеть в углу и что-то там извращать локально в /usr/local !

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

Re: [devel] Re: alternatives && postfix

[Egor S. Orlov]

On Mon, 09 Feb 2004 23:01:04 +0300
Alexey Lubimov <avl@l14.ru> wrote:

> > пересобирать пока не получается,
> > ему la-файлов от libgtk+2-devel сильно хочется
> 
> У меня нормально собрался и в сизиф и в мастер.
> Заодно (имхо) удачно  распилил на pygtk2 pygtk2-devel и pygtk2-examples.
> 
> 
> ftp://ftp.atmsk.ru/pub/distributions/SRPMS.sisyphus/pygtk2-2.0.0-avl11.src.rpm

с вашим пакетом у меня аналогично с моим

grep: /usr/lib/libgtk-x11-2.0.la: No such file or directory
/bin/sed: can't read /usr/lib/libgtk-x11-2.0.la: No such file or directory
libtool: link: `/usr/lib/libgtk-x11-2.0.la' is not a valid libtool archive



-- 
WBR, Egor S. Orlov
FST SPbSPU

Re: [devel] Re: alternatives && postfix

[Egor S. Orlov]

On Mon, 09 Feb 2004 23:01:04 +0300
Alexey Lubimov <avl@l14.ru> wrote:

> > пересобирать пока не получается,
> > ему la-файлов от libgtk+2-devel сильно хочется
> 
> У меня нормально собрался и в сизиф и в мастер.
> Заодно (имхо) удачно  распилил на pygtk2 pygtk2-devel и pygtk2-examples.
> 
> 
> ftp://ftp.atmsk.ru/pub/distributions/SRPMS.sisyphus/pygtk2-2.0.0-avl11.src.rpm

с вашим пакетом у меня аналогично с моим

grep: /usr/lib/libgtk-x11-2.0.la: No such file or directory
/bin/sed: can't read /usr/lib/libgtk-x11-2.0.la: No such file or directory
libtool: link: `/usr/lib/libgtk-x11-2.0.la' is not a valid libtool archive



-- 
WBR, Egor S. Orlov
FST SPbSPU

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 04:27, Alexey Tourbin wrote:
> Если бы в сизифе был всего один питон, то было бы единое пространство
> зависимостей.  Также можно было бы отказаться от versioned каталогов и
> т.д.  Это автоматически решает большую часть проблем.  С перлом так и

Каких? Вот все мне говорят, "это решает большую часть проблем". Единственная
пролема, которая реально всплывает - недопинанный мантейнер, не пересобравший пакет
с новым питоном. Теперь, пожайлуста, ответте:

1. Как отказ от двух питонов решает _эту_ проблему? (Собственно весь разговоримено
этой проблемой на этот раз и вызван).

2. Какие еще проблемы вызывает наличие двух питонов? (Одна реально есть, я он ней
писал, решается отказом пользователя - добровольшным или принудительным - от установки
двух  питонов);

Если можете ответить - отвечайте, нет - кончайте переливать из пустого в порожнее. Если
руками пакеты из 22/site-packages в 23/site-packages не копировать - проблем нет.

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 04:27, Alexey Tourbin wrote:
> Если бы в сизифе был всего один питон, то было бы единое пространство
> зависимостей.  Также можно было бы отказаться от versioned каталогов и
> т.д.  Это автоматически решает большую часть проблем.  С перлом так и

Каких? Вот все мне говорят, "это решает большую часть проблем". Единственная
пролема, которая реально всплывает - недопинанный мантейнер, не пересобравший пакет
с новым питоном. Теперь, пожайлуста, ответте:

1. Как отказ от двух питонов решает _эту_ проблему? (Собственно весь разговоримено
этой проблемой на этот раз и вызван).

2. Какие еще проблемы вызывает наличие двух питонов? (Одна реально есть, я он ней
писал, решается отказом пользователя - добровольшным или принудительным - от установки
двух  питонов);

Если можете ответить - отвечайте, нет - кончайте переливать из пустого в порожнее. Если
руками пакеты из 22/site-packages в 23/site-packages не копировать - проблем нет.

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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Mon, Feb 09, 2004 at 08:29:41PM +0200, Michael Shigorin wrote:
> On Mon, Feb 09, 2004 at 09:09:33PM +0300, Andrey Orlov wrote:
> > Опять 25ть. Перечитайте мои письма на эту тему и пинайте
> > мантейнеров пакетов, не пересобравших свои пакеты с python23.
> Мож версионирование Requires: python устрожить?
Не поможет :-/

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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Mon, Feb 09, 2004 at 08:29:41PM +0200, Michael Shigorin wrote:
> On Mon, Feb 09, 2004 at 09:09:33PM +0300, Andrey Orlov wrote:
> > Опять 25ть. Перечитайте мои письма на эту тему и пинайте
> > мантейнеров пакетов, не пересобравших свои пакеты с python23.
> Мож версионирование Requires: python устрожить?
Не поможет :-/

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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Mon, Feb 09, 2004 at 10:13:05PM +0300, Andrey Orlov wrote:
> Все рассказы про то, что "у нас питон по  умолчанию указывает 
> теперь на python23" - тут совершенно не при чем. 
> Пинайте мантейнера, чбы пересобрал под python23! Я еще раз утверждаю,
> __никакой__ проблемы нет. Есть просто непонимание и нежелание разбираться,
> а также откровенно некорректные высказывания.
У нас на борту ДВА питона.

<offtopic>
Процесс перевода приложений с питонаX на питонY занимает ненулевое
время. В условиях БОЛЬШОГО репозитория и БОЛЬШОГО количества людей,
которые собирают питоньи модуля, время это будет только расти.

В течение этого времени апт НЕ ловит того факта, что часть
модулей для программ, которые запускаются через /usr/bin/python
ПЕРЕСТАЛА грузиться (и НЕ СМОЖЕТ поймать, учитывая то, что
сосуществование pythonX и pythonY вполне законно)

В условиях того, что с питоном подобная ЖОПА случается ДВА РАЗА В ГОД (с
перлом, по крайней мере, arch-independent модуля относительно спокойно
переезжают из одной майнор версии в другую, да и скорость выхода новых
версий СУЩЕСТВЕННО ниже), я НЕ хочу, завидев новую версию, тут же
кидаться проверять челововеко-месяцы и -годы кода на то, что ничего не
сломается при переезде. У меня просто нет такой физической возможности.
У меня так же есть мало желания хвататься и пересобирать всю ботву на
самый модный (в терминологии Андрея: самый последний) питон.

Кроме того, мне НАДО поддерживать старые релизы. И мне НАДО будет
убеждаться, что софтина заработает в том окружении, которое стоит у
заказчика. И организация "виртуального окружения" существенно усложняет
жизнь обычного девелопера, которому _каждый день_ приходится править
ошибки в старых версиях (или, по крайней мере, быть готовым к этому).
</offtopic>

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


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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Mon, Feb 09, 2004 at 10:13:05PM +0300, Andrey Orlov wrote:
> Все рассказы про то, что "у нас питон по  умолчанию указывает 
> теперь на python23" - тут совершенно не при чем. 
> Пинайте мантейнера, чбы пересобрал под python23! Я еще раз утверждаю,
> __никакой__ проблемы нет. Есть просто непонимание и нежелание разбираться,
> а также откровенно некорректные высказывания.
У нас на борту ДВА питона.

<offtopic>
Процесс перевода приложений с питонаX на питонY занимает ненулевое
время. В условиях БОЛЬШОГО репозитория и БОЛЬШОГО количества людей,
которые собирают питоньи модуля, время это будет только расти.

В течение этого времени апт НЕ ловит того факта, что часть
модулей для программ, которые запускаются через /usr/bin/python
ПЕРЕСТАЛА грузиться (и НЕ СМОЖЕТ поймать, учитывая то, что
сосуществование pythonX и pythonY вполне законно)

В условиях того, что с питоном подобная ЖОПА случается ДВА РАЗА В ГОД (с
перлом, по крайней мере, arch-independent модуля относительно спокойно
переезжают из одной майнор версии в другую, да и скорость выхода новых
версий СУЩЕСТВЕННО ниже), я НЕ хочу, завидев новую версию, тут же
кидаться проверять челововеко-месяцы и -годы кода на то, что ничего не
сломается при переезде. У меня просто нет такой физической возможности.
У меня так же есть мало желания хвататься и пересобирать всю ботву на
самый модный (в терминологии Андрея: самый последний) питон.

Кроме того, мне НАДО поддерживать старые релизы. И мне НАДО будет
убеждаться, что софтина заработает в том окружении, которое стоит у
заказчика. И организация "виртуального окружения" существенно усложняет
жизнь обычного девелопера, которому _каждый день_ приходится править
ошибки в старых версиях (или, по крайней мере, быть готовым к этому).
</offtopic>

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


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

Re: [devel] Re: alternatives && postfix

[Алексей Любимов]

Andrey Orlov пишет:

>On Tuesday 10 February 2004 01:31, Alexey Lubimov wrote:
>  
>
>>>Вот в этом и есть корень вашей проблемы. Солюшен такой:
>>>
>>>1.  Сносите python22
>>>      
>>>
>>у меня пара серверов с зопом на питоне 2.2 крутится + несколько машин с
>>мастерами/сизифами разной свежести. их поддерживать надо. Так что не
>>вариант.
>>    
>>
>
>Кажется кто-то только сегодня докладывал, что сервер & сизиф - вещи несовместимые?
>
ага. но это уже признано флеймом.
и потом, речь идет о машине для разработки/поддержки, а не о сервере.

>Не вы ли? Ну так вот. К сожалению. При условии, что у вас на машине стоят оба питона,
>система зависимостей может иметь множественные решения, не все из которых имеют смысл.
>
>Пример такого бессмысленного решения:
>
> zope требует c
>
> zope требует d
>
> с  требует python22
>
> d требует python23
>
> zope требует python23
>  
>

zope требует или  c22 d23
zope требует c22  d22

zope требует c23  d22  или c22  d23  - ошибка сборки

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

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

г. Морозов грозился рассекретить свои мысли на данный счет...


> Если добавить ограничение "python23 конфликтует с python22" - то все нормально
>
это не решение.
 python23 и python22 не конфликтуют друг с другом.

>>>3.  Еще раз напоминаю, python22 - только для разработчиков. Так как
>>>"иногда надо для опытов". В дистрибутив этот пакет скорее всего не
>>>войдет.
>>>      
>>>
>>боюсь, что такая постановка вопроса из разряда "одна libdb4X.X, один
>>gcc, одно ядро etc". Здорово, но нереально...
>>    
>>
>
>В  данном случае - реально. Я уже не первый раз прошу предъявить мне пакет, принципиально
>не пересобираемый с python23. Так что не надо гнать.
>
не тот случай.  соберется, может, и все. а вот работать не _обязано_.
За zope со всеми используемыми в нем продуктами лично я не поручусь...

>Еще раз, для всех: тот, кто хочет разрабатывать на python22 _должен_ ставить мастер22. Тот, 
>кто хочет разрабатывать на python21 - мастер 20. Тот, кто хочет разрабатывать на python1.52 -
>я уж даже не помню, что он должен поставить, но никак не сизиф. 
>  
>
По крайней мере, здесь позиция ясна. Осталось донести ее до сознания 
всех заинтересованных лиц.

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Tue, Feb 10, 2004 at 09:52:31AM +0300, Andrey Orlov wrote:
> On Tuesday 10 February 2004 04:27, Alexey Tourbin wrote:
> > Если бы в сизифе был всего один питон, то было бы единое пространство
> > зависимостей.  Также можно было бы отказаться от versioned каталогов и
> > т.д.  Это автоматически решает большую часть проблем.  С перлом так и

> 1. Как отказ от двух питонов решает _эту_ проблему? (Собственно весь разговоримено
> этой проблемой на этот раз и вызван).
Элементарно. При удалении (аптом) pythonX, на который стоят зависимости
у pyPackageX, pyPackageY итп, эти самые pyPackage* либо попытаются
проапгрейдиться, если есть новая версия, либо уйдут в цифровое небытие.

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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Tue, Feb 10, 2004 at 09:52:31AM +0300, Andrey Orlov wrote:
> On Tuesday 10 February 2004 04:27, Alexey Tourbin wrote:
> > Если бы в сизифе был всего один питон, то было бы единое пространство
> > зависимостей.  Также можно было бы отказаться от versioned каталогов и
> > т.д.  Это автоматически решает большую часть проблем.  С перлом так и

> 1. Как отказ от двух питонов решает _эту_ проблему? (Собственно весь разговоримено
> этой проблемой на этот раз и вызван).
Элементарно. При удалении (аптом) pythonX, на который стоят зависимости
у pyPackageX, pyPackageY итп, эти самые pyPackage* либо попытаются
проапгрейдиться, если есть новая версия, либо уйдут в цифровое небытие.

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

Re: [devel] Re: alternatives && postfix

[Алексей Любимов]

Andrey Orlov пишет:

>On Tuesday 10 February 2004 01:31, Alexey Lubimov wrote:
>  
>
>>>Вот в этом и есть корень вашей проблемы. Солюшен такой:
>>>
>>>1.  Сносите python22
>>>      
>>>
>>у меня пара серверов с зопом на питоне 2.2 крутится + несколько машин с
>>мастерами/сизифами разной свежести. их поддерживать надо. Так что не
>>вариант.
>>    
>>
>
>Кажется кто-то только сегодня докладывал, что сервер & сизиф - вещи несовместимые?
>
ага. но это уже признано флеймом.
и потом, речь идет о машине для разработки/поддержки, а не о сервере.

>Не вы ли? Ну так вот. К сожалению. При условии, что у вас на машине стоят оба питона,
>система зависимостей может иметь множественные решения, не все из которых имеют смысл.
>
>Пример такого бессмысленного решения:
>
> zope требует c
>
> zope требует d
>
> с  требует python22
>
> d требует python23
>
> zope требует python23
>  
>

zope требует или  c22 d23
zope требует c22  d22

zope требует c23  d22  или c22  d23  - ошибка сборки

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

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

г. Морозов грозился рассекретить свои мысли на данный счет...


> Если добавить ограничение "python23 конфликтует с python22" - то все нормально
>
это не решение.
 python23 и python22 не конфликтуют друг с другом.

>>>3.  Еще раз напоминаю, python22 - только для разработчиков. Так как
>>>"иногда надо для опытов". В дистрибутив этот пакет скорее всего не
>>>войдет.
>>>      
>>>
>>боюсь, что такая постановка вопроса из разряда "одна libdb4X.X, один
>>gcc, одно ядро etc". Здорово, но нереально...
>>    
>>
>
>В  данном случае - реально. Я уже не первый раз прошу предъявить мне пакет, принципиально
>не пересобираемый с python23. Так что не надо гнать.
>
не тот случай.  соберется, может, и все. а вот работать не _обязано_.
За zope со всеми используемыми в нем продуктами лично я не поручусь...

>Еще раз, для всех: тот, кто хочет разрабатывать на python22 _должен_ ставить мастер22. Тот, 
>кто хочет разрабатывать на python21 - мастер 20. Тот, кто хочет разрабатывать на python1.52 -
>я уж даже не помню, что он должен поставить, но никак не сизиф. 
>  
>
По крайней мере, здесь позиция ясна. Осталось донести ее до сознания 
всех заинтересованных лиц.

[devel] Re: alternatives && postfix

[Andrey Khavryuchenko]

Alexey,

"AM" == Alexey Morozov wrote:

 AM> В условиях того, что с питоном подобная ЖОПА случается ДВА РАЗА В ГОД (с

Не чаще раза в год.  RTFM.

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

[devel] Re: alternatives && postfix

[Andrey Khavryuchenko]

Alexey,

"AM" == Alexey Morozov wrote:

 AM> В условиях того, что с питоном подобная ЖОПА случается ДВА РАЗА В ГОД (с

Не чаще раза в год.  RTFM.

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Tue, Feb 10, 2004 at 10:43:04AM +0300, Алексей Любимов wrote:
> весь вопрос, какой кровью обойдется такая сборка и как ее сделать 
> максимально прозрачной. В идеале, из одного src.rpm оба варианта.
> 
> г. Морозов грозился рассекретить свои мысли на данный счет...
Мои мысли давно рассекречены и лежат (в виде примеров пакетов
некототорой степени свежести) на http://woland.iae.nsk.su/~alex/python/

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

	2. наверное, стоит отказаться от одновременной сборки пакета
	   под две версии, в противном случае необходимо организовать
	   автоматическую генерацию пакетов (хе-хе, это будет непросто)
	   
	3. необходимо причесать макросы, используемые для питона, там
	   много простых повторяющихся моментов.
	 
> >Еще раз, для всех: тот, кто хочет разрабатывать на python22 _должен_ 
> >ставить мастер22. Тот, кто хочет разрабатывать на python21 - мастер 20. 
> >Тот, кто хочет разрабатывать на python1.52 -
> >я уж даже не помню, что он должен поставить, но никак не сизиф. 
> По крайней мере, здесь позиция ясна. Осталось донести ее до сознания 
> всех заинтересованных лиц.
<flame>
Даешь по четыре машины на каждого девелупера! Им ведь с этим кодом
_работать_ надо, а не просто смотреть на его [не]работоспособность.
А работа - это не просто pythonX и pyPackageY, pyPackageZ итп. Это еще и
те либы, которые цепляются в проекте, и возможность проверять код в
своем _привычном_ девелоперском окружении (читай: из редактора) итп.
</flame>


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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Tue, Feb 10, 2004 at 10:43:04AM +0300, Алексей Любимов wrote:
> весь вопрос, какой кровью обойдется такая сборка и как ее сделать 
> максимально прозрачной. В идеале, из одного src.rpm оба варианта.
> 
> г. Морозов грозился рассекретить свои мысли на данный счет...
Мои мысли давно рассекречены и лежат (в виде примеров пакетов
некототорой степени свежести) на http://woland.iae.nsk.su/~alex/python/

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

	2. наверное, стоит отказаться от одновременной сборки пакета
	   под две версии, в противном случае необходимо организовать
	   автоматическую генерацию пакетов (хе-хе, это будет непросто)
	   
	3. необходимо причесать макросы, используемые для питона, там
	   много простых повторяющихся моментов.
	 
> >Еще раз, для всех: тот, кто хочет разрабатывать на python22 _должен_ 
> >ставить мастер22. Тот, кто хочет разрабатывать на python21 - мастер 20. 
> >Тот, кто хочет разрабатывать на python1.52 -
> >я уж даже не помню, что он должен поставить, но никак не сизиф. 
> По крайней мере, здесь позиция ясна. Осталось донести ее до сознания 
> всех заинтересованных лиц.
<flame>
Даешь по четыре машины на каждого девелупера! Им ведь с этим кодом
_работать_ надо, а не просто смотреть на его [не]работоспособность.
А работа - это не просто pythonX и pyPackageY, pyPackageZ итп. Это еще и
те либы, которые цепляются в проекте, и возможность проверять код в
своем _привычном_ девелоперском окружении (читай: из редактора) итп.
</flame>


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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 10:42, Alexey Morozov wrote:
> В течение этого времени апт НЕ ловит того факта, что часть
> модулей для программ, которые запускаются через /usr/bin/python
> ПЕРЕСТАЛА грузиться (и НЕ СМОЖЕТ поймать, учитывая то, что
> сосуществование pythonX и pythonY вполне законно)

Это я принимаю. Conflict python22 будет добавлен в ближайшей сборке
python23. Такая проблема действительно есть, причины ее возникновения 
я только что описал.

> У меня так же есть мало желания хвататься и пересобирать всю ботву на

Откажитесь от части взятых на себя пакетов, появится время.

> Кроме того, мне НАДО поддерживать старые релизы. И мне НАДО будет
> убеждаться, что софтина заработает в том окружении, которое стоит у
> заказчика. И организация "виртуального окружения" существенно усложняет

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

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

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

> Я больше к Вам с этими предложениями не лезу. Мне тоже
> работать надо.

Я не видел от вам еще ни одного прделожения, сформулированного в достаточной 
степени чбы о нем можно было говорить. Если увижу - будем обсуждать. Плиз:

1. Проблема, которую решает ваше предложение;
2. Суть самого предложения.

До сих пор я видел два варианта предложений:

1. Держатиь один питон - эмулируется сносом лишнего питона, поскольку есть реальная проблема
которую это решает, я решил добавить конфликт в пакет python23, его совместная установка
с python22 станет невозможной и одна конкрентная проблема будет решена.
2. Держать два комплекта пакетов - если кратко, то это невозможно. В частности, простая
задача upgrade, которая сейчас худо-бедно решается после пересборки необходимых пакетов
становится неразрешимой.

Еще предложения есть?

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 10:45, Alexey Morozov wrote:
> > 1. Как отказ от двух питонов решает _эту_ проблему? (Собственно весь
> > разговоримено этой проблемой на этот раз и вызван).
>
> Элементарно. При удалении (аптом) pythonX, на который стоят зависимости
> у pyPackageX, pyPackageY итп, эти самые pyPackage* либо попытаются
> проапгрейдиться, если есть новая версия, либо уйдут в цифровое небытие.

Буквально только что некий Алексей Любимов запустил питон23 и старый pygtk2 (пересобранный
с python22) и убедился что он не работает. По крайней мере он так утверждает. А вы предлагаете
это как решение проблемы. Так что это предложение создает проблемы а не решает их. Еще 
предложения есть?


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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 10:42, Alexey Morozov wrote:
> В течение этого времени апт НЕ ловит того факта, что часть
> модулей для программ, которые запускаются через /usr/bin/python
> ПЕРЕСТАЛА грузиться (и НЕ СМОЖЕТ поймать, учитывая то, что
> сосуществование pythonX и pythonY вполне законно)

Это я принимаю. Conflict python22 будет добавлен в ближайшей сборке
python23. Такая проблема действительно есть, причины ее возникновения 
я только что описал.

> У меня так же есть мало желания хвататься и пересобирать всю ботву на

Откажитесь от части взятых на себя пакетов, появится время.

> Кроме того, мне НАДО поддерживать старые релизы. И мне НАДО будет
> убеждаться, что софтина заработает в том окружении, которое стоит у
> заказчика. И организация "виртуального окружения" существенно усложняет

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

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

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

> Я больше к Вам с этими предложениями не лезу. Мне тоже
> работать надо.

Я не видел от вам еще ни одного прделожения, сформулированного в достаточной 
степени чбы о нем можно было говорить. Если увижу - будем обсуждать. Плиз:

1. Проблема, которую решает ваше предложение;
2. Суть самого предложения.

До сих пор я видел два варианта предложений:

1. Держатиь один питон - эмулируется сносом лишнего питона, поскольку есть реальная проблема
которую это решает, я решил добавить конфликт в пакет python23, его совместная установка
с python22 станет невозможной и одна конкрентная проблема будет решена.
2. Держать два комплекта пакетов - если кратко, то это невозможно. В частности, простая
задача upgrade, которая сейчас худо-бедно решается после пересборки необходимых пакетов
становится неразрешимой.

Еще предложения есть?

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 10:45, Alexey Morozov wrote:
> > 1. Как отказ от двух питонов решает _эту_ проблему? (Собственно весь
> > разговоримено этой проблемой на этот раз и вызван).
>
> Элементарно. При удалении (аптом) pythonX, на который стоят зависимости
> у pyPackageX, pyPackageY итп, эти самые pyPackage* либо попытаются
> проапгрейдиться, если есть новая версия, либо уйдут в цифровое небытие.

Буквально только что некий Алексей Любимов запустил питон23 и старый pygtk2 (пересобранный
с python22) и убедился что он не работает. По крайней мере он так утверждает. А вы предлагаете
это как решение проблемы. Так что это предложение создает проблемы а не решает их. Еще 
предложения есть?


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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 10:43, Алексей Любимов wrote:
> > Если добавить ограничение "python23 конфликтует с python22" - то все
> > нормально
>
> это не решение.
>  python23 и python22 не конфликтуют друг с другом.

Это решение, так как делает бессмысленную систему несовместной.

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 10:43, Алексей Любимов wrote:
> > Если добавить ограничение "python23 конфликтует с python22" - то все
> > нормально
>
> это не решение.
>  python23 и python22 не конфликтуют друг с другом.

Это решение, так как делает бессмысленную систему несовместной.

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 10:43, Алексей Любимов wrote:
> не тот случай.  соберется, может, и все. а вот работать не _обязано_.

Оно и со старым работать не обязано ;), тестировать надо.

> За zope со всеми используемыми в нем продуктами лично я не поручусь...

Ни одна версия Zope ни с одной из версий python не работоспосбона со всеми написаными
для него продуктами. За это я поручусь. Если вы знаете о неработоспособности текущей	
версии zope В сизифе с какими либо пакетами, наличиствующими в сизифе - пожалуста,
баг либо на пакет, либо на Zope.

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 10:43, Алексей Любимов wrote:
> не тот случай.  соберется, может, и все. а вот работать не _обязано_.

Оно и со старым работать не обязано ;), тестировать надо.

> За zope со всеми используемыми в нем продуктами лично я не поручусь...

Ни одна версия Zope ни с одной из версий python не работоспосбона со всеми написаными
для него продуктами. За это я поручусь. Если вы знаете о неработоспособности текущей	
версии zope В сизифе с какими либо пакетами, наличиствующими в сизифе - пожалуста,
баг либо на пакет, либо на Zope.

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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Tue, Feb 10, 2004 at 09:55:25AM +0200, Andrey Khavryuchenko wrote:
> Alexey,
> 
> "AM" == Alexey Morozov wrote:
> 
>  AM> В условиях того, что с питоном подобная ЖОПА случается ДВА РАЗА В ГОД (с
> Не чаще раза в год.  RTFM.
Я боюсь приписать эту информацию Андрею Орлову, он сильно обижается на
мои "оценочные" фразы, но готов поклясться, что про два раза в год я
слышал в списках рассылки @altlinux.ru от /кого-то, кто имеет отношение
к сборке питона и/или его модулей/. Специально для Андрея: я НЕ имею
ввиду Вас, мне просто кажется, что это был достаточно компетентный в
данном вопросе человек из ALT.

По существу вопроса: да, срок выхода новой "minor" версии питона
по-видимому, около года (между 2.1 и 2.2 прошло восемь месяцев,
а между 2.2 и 2.3 - полтора). Впрочем, можно ли было использовать в
продакшне stock 2.2 и 2.3 я не знаю, такого опыта у меня нет.



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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Tue, Feb 10, 2004 at 09:55:25AM +0200, Andrey Khavryuchenko wrote:
> Alexey,
> 
> "AM" == Alexey Morozov wrote:
> 
>  AM> В условиях того, что с питоном подобная ЖОПА случается ДВА РАЗА В ГОД (с
> Не чаще раза в год.  RTFM.
Я боюсь приписать эту информацию Андрею Орлову, он сильно обижается на
мои "оценочные" фразы, но готов поклясться, что про два раза в год я
слышал в списках рассылки @altlinux.ru от /кого-то, кто имеет отношение
к сборке питона и/или его модулей/. Специально для Андрея: я НЕ имею
ввиду Вас, мне просто кажется, что это был достаточно компетентный в
данном вопросе человек из ALT.

По существу вопроса: да, срок выхода новой "minor" версии питона
по-видимому, около года (между 2.1 и 2.2 прошло восемь месяцев,
а между 2.2 и 2.3 - полтора). Впрочем, можно ли было использовать в
продакшне stock 2.2 и 2.3 я не знаю, такого опыта у меня нет.



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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 11:04, Alexey Morozov wrote:
> <flame>
> Даешь по четыре машины на каждого девелупера! Им ведь с этим кодом
> _работать_ надо, а не просто смотреть на его [не]работоспособность.
> А работа - это не просто pythonX и pyPackageY, pyPackageZ итп. Это еще и
> те либы, которые цепляются в проекте, и возможность проверять код в
> своем _привычном_ девелоперском окружении (читай: из редактора) итп.
> </flame>

У меня три среды - для сборки под master22, ASP, и сизифа - стоят на одной машине
и доступны _одновременно_. И так уже не первый год. Я совершенно спокойно
работаю и это не вызывает ровным счетом никаких проблем. Почитайте man chroot.
Пару раз ко мне обращались люди, которым нужна была среда для сборки под сизиф, 
а сами они работали либо в редхэт, либо в asp - я им об этом рассказал и у них это тоже
сработало. Попробуйте и вы, это действително нетрудна.

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

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 11:04, Alexey Morozov wrote:
> <flame>
> Даешь по четыре машины на каждого девелупера! Им ведь с этим кодом
> _работать_ надо, а не просто смотреть на его [не]работоспособность.
> А работа - это не просто pythonX и pyPackageY, pyPackageZ итп. Это еще и
> те либы, которые цепляются в проекте, и возможность проверять код в
> своем _привычном_ девелоперском окружении (читай: из редактора) итп.
> </flame>

У меня три среды - для сборки под master22, ASP, и сизифа - стоят на одной машине
и доступны _одновременно_. И так уже не первый год. Я совершенно спокойно
работаю и это не вызывает ровным счетом никаких проблем. Почитайте man chroot.
Пару раз ко мне обращались люди, которым нужна была среда для сборки под сизиф, 
а сами они работали либо в редхэт, либо в asp - я им об этом рассказал и у них это тоже
сработало. Попробуйте и вы, это действително нетрудна.

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

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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Tue, Feb 10, 2004 at 11:11:30AM +0300, Andrey Orlov wrote:
> On Tuesday 10 February 2004 10:45, Alexey Morozov wrote:
> > > 1. Как отказ от двух питонов решает _эту_ проблему? (Собственно весь
> > > разговоримено этой проблемой на этот раз и вызван).
> >
> > Элементарно. При удалении (аптом) pythonX, на который стоят зависимости
> > у pyPackageX, pyPackageY итп, эти самые pyPackage* либо попытаются
> > проапгрейдиться, если есть новая версия, либо уйдут в цифровое небытие.
> 
> Буквально только что некий Алексей Любимов запустил питон23 и старый pygtk2 (пересобранный
> с python22) и убедился что он не работает. По крайней мере он так утверждает. А вы предлагаете
> это как решение проблемы. Так что это предложение создает проблемы а не решает их. Еще 
> предложения есть?

Андрей, мне неудобно Вам об этом говорить, но Вы передергиваете.

"Как отказ от двух питонов решает эту проблему?"

Каждый приличный (можно попросить Дмитрия Левина, чтобы он сделал это
_правилом_) питон-модуль должен держать в потрохах:

Requires: python = %__python_version

При этом снесение (н-р, в ходе апгрейда) python<тот самый вёршн>
автоматически приводит к тому, что зависимости на python = <тот самый
вершн> оказываются неудовлетворены (хех, кто перевод придумывал :-)).
За этим следует предложение (апта) либо проапгрейдить все попавшие под
нож модули, либо снести их.

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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Tue, Feb 10, 2004 at 11:11:30AM +0300, Andrey Orlov wrote:
> On Tuesday 10 February 2004 10:45, Alexey Morozov wrote:
> > > 1. Как отказ от двух питонов решает _эту_ проблему? (Собственно весь
> > > разговоримено этой проблемой на этот раз и вызван).
> >
> > Элементарно. При удалении (аптом) pythonX, на который стоят зависимости
> > у pyPackageX, pyPackageY итп, эти самые pyPackage* либо попытаются
> > проапгрейдиться, если есть новая версия, либо уйдут в цифровое небытие.
> 
> Буквально только что некий Алексей Любимов запустил питон23 и старый pygtk2 (пересобранный
> с python22) и убедился что он не работает. По крайней мере он так утверждает. А вы предлагаете
> это как решение проблемы. Так что это предложение создает проблемы а не решает их. Еще 
> предложения есть?

Андрей, мне неудобно Вам об этом говорить, но Вы передергиваете.

"Как отказ от двух питонов решает эту проблему?"

Каждый приличный (можно попросить Дмитрия Левина, чтобы он сделал это
_правилом_) питон-модуль должен держать в потрохах:

Requires: python = %__python_version

При этом снесение (н-р, в ходе апгрейда) python<тот самый вёршн>
автоматически приводит к тому, что зависимости на python = <тот самый
вершн> оказываются неудовлетворены (хех, кто перевод придумывал :-)).
За этим следует предложение (апта) либо проапгрейдить все попавшие под
нож модули, либо снести их.

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 11:30, Alexey Morozov wrote:
> Андрей, мне неудобно Вам об этом говорить, но Вы передергиваете.
> "Как отказ от двух питонов решает эту проблему?"
>
> Каждый приличный (можно попросить Дмитрия Левина, чтобы он сделал это
> _правилом_) питон-модуль должен держать в потрохах:

Я уже извинился за невнимательное прочтения, извиняюсь еще раз. ПРосто у меня во
всех пакетах это стоит и меня удивило то, что у кого-то это не стоит. С эти требованием
я согласен и сам ему, как видите, следую. Но наличие двух питонов при этом проблемы не
создает, а отказ - не решает. ПОдрбоности см. в предыдущем письме, как я уже грил - конфликт
я добавлю, будет у вас python22 автоматически сносится при установке python23, все осталньое
по зависимостям есть и так.

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 11:30, Alexey Morozov wrote:
> Андрей, мне неудобно Вам об этом говорить, но Вы передергиваете.
> "Как отказ от двух питонов решает эту проблему?"
>
> Каждый приличный (можно попросить Дмитрия Левина, чтобы он сделал это
> _правилом_) питон-модуль должен держать в потрохах:

Я уже извинился за невнимательное прочтения, извиняюсь еще раз. ПРосто у меня во
всех пакетах это стоит и меня удивило то, что у кого-то это не стоит. С эти требованием
я согласен и сам ему, как видите, следую. Но наличие двух питонов при этом проблемы не
создает, а отказ - не решает. ПОдрбоности см. в предыдущем письме, как я уже грил - конфликт
я добавлю, будет у вас python22 автоматически сносится при установке python23, все осталньое
по зависимостям есть и так.

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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Tue, Feb 10, 2004 at 11:11:11AM +0300, Andrey Orlov wrote:
> On Tuesday 10 February 2004 10:42, Alexey Morozov wrote:
> Это я принимаю. Conflict python22 будет добавлен в ближайшей сборке
> python23. Такая проблема действительно есть, причины ее возникновения 
> я только что описал.
Сделайте, пожалуйста, не Conflict, а Obsoletes. Вам все равно, а мне (и
остальным, которым рабо^H^H^H^H нужны старые версии питон) будет легче.

> > У меня так же есть мало желания хвататься и пересобирать всю ботву на
> Откажитесь от части взятых на себя пакетов, появится время.
:-) У меня нет пакетов в Сизифе
Ну, точнее, почти нет.

> А что собственно вы предлагаете? Давайте вы это перечислите, а я укажу
> вам какие проблемы это на самом деле вызывает? 
См. выше про Conflicts vs. Obsoletes

См. выше про единую схему именования модулей для питон вида

python<pversion>-moduleName

Второе - это не серебряная пуля, но, по крайней мере, позволяет
осуществлять визуальный контроль из командной строки и позволяет держать
два комплекта модулей ДЛЯ ТЕХ, КОМУ ЭТО НУЖНО.


> задача upgrade, которая сейчас худо-бедно решается после пересборки
> необходимых пакетов становится неразрешимой.
Андрей, Вы поверите, что проблем с апгрейдом пакетов в рамках одной
версии питона и проблем с апгрейдом модулей при смене версии питона
в этом случае не больше, чем при любом другом апгрейде, где существует
множественность версий софта? Можете провести блиц-опрос на тему:

нужен ли в репозитории gcc3.2, если GGC Team уже осчастливила нас
выпуском gcc3.3? И как опращиваемые отнесутся к перспективе дружными
рядами сесть переписывать все хозяйство под 3.3?


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

Re: [devel] Re: alternatives && postfix

[Alexey Morozov]

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

On Tue, Feb 10, 2004 at 11:11:11AM +0300, Andrey Orlov wrote:
> On Tuesday 10 February 2004 10:42, Alexey Morozov wrote:
> Это я принимаю. Conflict python22 будет добавлен в ближайшей сборке
> python23. Такая проблема действительно есть, причины ее возникновения 
> я только что описал.
Сделайте, пожалуйста, не Conflict, а Obsoletes. Вам все равно, а мне (и
остальным, которым рабо^H^H^H^H нужны старые версии питон) будет легче.

> > У меня так же есть мало желания хвататься и пересобирать всю ботву на
> Откажитесь от части взятых на себя пакетов, появится время.
:-) У меня нет пакетов в Сизифе
Ну, точнее, почти нет.

> А что собственно вы предлагаете? Давайте вы это перечислите, а я укажу
> вам какие проблемы это на самом деле вызывает? 
См. выше про Conflicts vs. Obsoletes

См. выше про единую схему именования модулей для питон вида

python<pversion>-moduleName

Второе - это не серебряная пуля, но, по крайней мере, позволяет
осуществлять визуальный контроль из командной строки и позволяет держать
два комплекта модулей ДЛЯ ТЕХ, КОМУ ЭТО НУЖНО.


> задача upgrade, которая сейчас худо-бедно решается после пересборки
> необходимых пакетов становится неразрешимой.
Андрей, Вы поверите, что проблем с апгрейдом пакетов в рамках одной
версии питона и проблем с апгрейдом модулей при смене версии питона
в этом случае не больше, чем при любом другом апгрейде, где существует
множественность версий софта? Можете провести блиц-опрос на тему:

нужен ли в репозитории gcc3.2, если GGC Team уже осчастливила нас
выпуском gcc3.3? И как опращиваемые отнесутся к перспективе дружными
рядами сесть переписывать все хозяйство под 3.3?


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

[devel] Re: alternatives && postfix

[Vitaly Ostanin]

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

On Tue, 10 Feb 2004 11:11:30 +0300
Andrey Orlov <cray@neural.ru> wrote:

> On Tuesday 10 February 2004 10:45, Alexey Morozov wrote:
> > > 1. Как отказ от двух питонов решает _эту_ проблему?
> > > (Собственно весь разговоримено этой проблемой на этот раз и
> > > вызван).
> >
> > Элементарно. При удалении (аптом) pythonX, на который стоят
> > зависимости у pyPackageX, pyPackageY итп, эти самые
> > pyPackage* либо попытаются проапгрейдиться, если есть новая
> > версия, либо уйдут в цифровое небытие.
> 
> Буквально только что некий Алексей Любимов запустил питон23 и
> старый pygtk2 (пересобранный с python22) и убедился что он не
> работает. По крайней мере он так утверждает. А вы предлагаете
> это как решение проблемы. Так что это предложение создает
> проблемы а не решает их. Еще предложения есть?

Давайте немного повежливее.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

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

Re: [devel] [JT] alternatives && postfix

[Alexey Morozov]

On Tue, Feb 10, 2004 at 11:28:52AM +0300, Andrey Orlov wrote:
> Почитайте man chroot.
Андрей, Вы понимаете, что полсистемы уедет в chroot?

Я ведь говорю о _работе_ в этой среде.

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

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

Re: [devel] [JT] alternatives && postfix

[Alexey Morozov]

On Tue, Feb 10, 2004 at 11:28:52AM +0300, Andrey Orlov wrote:
> Почитайте man chroot.
Андрей, Вы понимаете, что полсистемы уедет в chroot?

Я ведь говорю о _работе_ в этой среде.

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

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

[devel] Re: alternatives && postfix

[Vitaly Ostanin]

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

On Tue, 10 Feb 2004 11:11:30 +0300
Andrey Orlov <cray@neural.ru> wrote:

> On Tuesday 10 February 2004 10:45, Alexey Morozov wrote:
> > > 1. Как отказ от двух питонов решает _эту_ проблему?
> > > (Собственно весь разговоримено этой проблемой на этот раз и
> > > вызван).
> >
> > Элементарно. При удалении (аптом) pythonX, на который стоят
> > зависимости у pyPackageX, pyPackageY итп, эти самые
> > pyPackage* либо попытаются проапгрейдиться, если есть новая
> > версия, либо уйдут в цифровое небытие.
> 
> Буквально только что некий Алексей Любимов запустил питон23 и
> старый pygtk2 (пересобранный с python22) и убедился что он не
> работает. По крайней мере он так утверждает. А вы предлагаете
> это как решение проблемы. Так что это предложение создает
> проблемы а не решает их. Еще предложения есть?

Давайте немного повежливее.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 11:42, Alexey Morozov wrote:
> Сделайте, пожалуйста, не Conflict, а Obsoletes. Вам все равно, а мне (и
> остальным, которым рабо^H^H^H^H нужны старые версии питон) будет легче.

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

> См. выше про Conflicts vs. Obsoletes

Принято.

> См. выше про единую схему именования модулей для питон вида
>
> python<pversion>-moduleName

Я против. Потому что: 

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

> Второе - это не серебряная пуля, но, по крайней мере, позволяет
> осуществлять визуальный контроль из командной строки и позволяет держать
> два комплекта модулей ДЛЯ ТЕХ, КОМУ ЭТО НУЖНО.

1. Кто будет пересобирать эти два комплекта? Автоматически это не получится
2. Это НИКОМУ НЕ НУЖНО.

> Андрей, Вы поверите, что проблем с апгрейдом пакетов в рамках одной
> версии питона и проблем с апгрейдом модулей при смене версии питона

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

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 11:42, Alexey Morozov wrote:
> Сделайте, пожалуйста, не Conflict, а Obsoletes. Вам все равно, а мне (и
> остальным, которым рабо^H^H^H^H нужны старые версии питон) будет легче.

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

> См. выше про Conflicts vs. Obsoletes

Принято.

> См. выше про единую схему именования модулей для питон вида
>
> python<pversion>-moduleName

Я против. Потому что: 

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

> Второе - это не серебряная пуля, но, по крайней мере, позволяет
> осуществлять визуальный контроль из командной строки и позволяет держать
> два комплекта модулей ДЛЯ ТЕХ, КОМУ ЭТО НУЖНО.

1. Кто будет пересобирать эти два комплекта? Автоматически это не получится
2. Это НИКОМУ НЕ НУЖНО.

> Андрей, Вы поверите, что проблем с апгрейдом пакетов в рамках одной
> версии питона и проблем с апгрейдом модулей при смене версии питона

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

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

Re: [devel] [JT] alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 11:46, Alexey Morozov wrote:
> А зачем так? Не проще ли сохранять список пакетов и откатывать его до
> стабильного состояния?

Мне проще - перегрузится. Если вам проще откатывать - откатывайте. 

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

Re: [devel] [JT] alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 11:46, Alexey Morozov wrote:
> А зачем так? Не проще ли сохранять список пакетов и откатывать его до
> стабильного состояния?

Мне проще - перегрузится. Если вам проще откатывать - откатывайте. 

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 11:46, Vitaly Ostanin wrote:
> Давайте немного повежливее.

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

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 11:46, Vitaly Ostanin wrote:
> Давайте немного повежливее.

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

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

[devel] Re: alternatives && postfix

[Michael Shigorin]

On Tue, Feb 10, 2004 at 09:47:42AM +0300, Egor S. Orlov wrote:
> grep: /usr/lib/libgtk-x11-2.0.la: No such file or directory

rpm -q libtool_1.5
?

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

[devel] Re: alternatives && postfix

[Michael Shigorin]

On Tue, Feb 10, 2004 at 09:47:42AM +0300, Egor S. Orlov wrote:
> grep: /usr/lib/libgtk-x11-2.0.la: No such file or directory

rpm -q libtool_1.5
?

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

Re: [devel] Re: alternatives && postfix

[Алексей Любимов]

>Мои мысли давно рассекречены и лежат (в виде примеров пакетов
>некототорой степени свежести) на http://woland.iae.nsk.su/~alex/python/
>  
>
оверхед уж больно большой. Изначальный трехстрочный спек уж больно 
мутным получается.
Лучше тогда скрипт наваять для генерации  спеков для разных питонов из 
одного исходного...

><flame>
>Даешь по четыре машины на каждого девелупера! Им ведь с этим кодом
>
>  
>
а тут пришел Морозов и вслух сказал то, о чем все и так подумали...

Re: [devel] Re: alternatives && postfix

[Egor S. Orlov]

On Tue, 10 Feb 2004 11:09:42 +0200
Michael Shigorin <mike@osdn.org.ua> wrote:

> On Tue, Feb 10, 2004 at 09:47:42AM +0300, Egor S. Orlov wrote:
> > grep: /usr/lib/libgtk-x11-2.0.la: No such file or directory
> 
> rpm -q libtool_1.5
> ?

libtool_1.5-1.5-alt11

по совету Юрия пересобрал gtkglarea без la
проблемма была в ней

если maintener (aen) будет не против - залью все в incoming

-- 
WBR, Egor S. Orlov
FST SPbSPU

Re: [devel] Re: alternatives && postfix

[Egor S. Orlov]

On Tue, 10 Feb 2004 11:09:42 +0200
Michael Shigorin <mike@osdn.org.ua> wrote:

> On Tue, Feb 10, 2004 at 09:47:42AM +0300, Egor S. Orlov wrote:
> > grep: /usr/lib/libgtk-x11-2.0.la: No such file or directory
> 
> rpm -q libtool_1.5
> ?

libtool_1.5-1.5-alt11

по совету Юрия пересобрал gtkglarea без la
проблемма была в ней

если maintener (aen) будет не против - залью все в incoming

-- 
WBR, Egor S. Orlov
FST SPbSPU

Re: [devel] Re: alternatives && postfix

[Алексей Любимов]

>Мои мысли давно рассекречены и лежат (в виде примеров пакетов
>некототорой степени свежести) на http://woland.iae.nsk.su/~alex/python/
>  
>
оверхед уж больно большой. Изначальный трехстрочный спек уж больно 
мутным получается.
Лучше тогда скрипт наваять для генерации  спеков для разных питонов из 
одного исходного...

><flame>
>Даешь по четыре машины на каждого девелупера! Им ведь с этим кодом
>
>  
>
а тут пришел Морозов и вслух сказал то, о чем все и так подумали...

[devel] Re: alternatives && postfix

[Michael Shigorin]

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

On Tue, Feb 10, 2004 at 12:20:13PM +0300, Egor S. Orlov wrote:
> > > grep: /usr/lib/libgtk-x11-2.0.la: No such file or directory
> > rpm -q libtool_1.5
> libtool_1.5-1.5-alt11
> по совету Юрия пересобрал gtkglarea без la проблемма была в ней
> если maintener (aen) будет не против - залью все в incoming

Добудьте для начала 1.5.2.

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

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

[devel] Re: alternatives && postfix

[Michael Shigorin]

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

On Tue, Feb 10, 2004 at 12:20:13PM +0300, Egor S. Orlov wrote:
> > > grep: /usr/lib/libgtk-x11-2.0.la: No such file or directory
> > rpm -q libtool_1.5
> libtool_1.5-1.5-alt11
> по совету Юрия пересобрал gtkglarea без la проблемма была в ней
> если maintener (aen) будет не против - залью все в incoming

Добудьте для начала 1.5.2.

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

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

Re: [devel] alternatives && postfix

[Grigory Milev]

>>>>> "mithraen" == mithraen  <mithraen@altlinux.ru> writes:
    >> Собственно есть предложение собрать postfix-sasl или что-то подобное и
    >> переключать его через альтернативы. Единственное но, как через
    >> альтернативы переключать /etc/chroot.d/postfix.lib и, кто этим
    >> займется?

    mithraen> Может сделать пакет postfix-sasl, который Provides: postfix и
    mithraen> Conflicts: postfix ? Ситуацию установленых на одной машине _и_
    mithraen> postfix _и_ postfix с sasl2 я себе слабо представляю.
Именно это я и предлагаю, иметь два postfix'а, ставишь нужный. Или второй
вариант - ставить оба и выбирать нужный через альтернативы.

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

Re: [devel] alternatives && postfix

[Grigory Milev]

>>>>> "mithraen" == mithraen  <mithraen@altlinux.ru> writes:
    >> Собственно есть предложение собрать postfix-sasl или что-то подобное и
    >> переключать его через альтернативы. Единственное но, как через
    >> альтернативы переключать /etc/chroot.d/postfix.lib и, кто этим
    >> займется?

    mithraen> Может сделать пакет postfix-sasl, который Provides: postfix и
    mithraen> Conflicts: postfix ? Ситуацию установленых на одной машине _и_
    mithraen> postfix _и_ postfix с sasl2 я себе слабо представляю.
Именно это я и предлагаю, иметь два postfix'а, ставишь нужный. Или второй
вариант - ставить оба и выбирать нужный через альтернативы.

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

Re: [devel] alternatives && postfix

[Grigory Milev]

>>>>> "Valery" == Valery V Inozemtsev <shrek@progroup.ru> writes:

    Valery> <skip>
    >> возможный вариант, но тогда postfix-sasl должен собираться со всеми
    >> опциями, которые есть сейчас в postfix???

    Valery> угу

    >> и как sasl2 живет с postfix в chroot'е?

    Valery> у меня вот так:

    Valery> /etc/sysconfig/saslauthd

    Valery> OPTIONS="-a pam -m /var/spool/postfix/var/run/saslauthd"
Аналогично, может кто-нить что-нить поизящнее предложит?

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

Re: [devel] alternatives && postfix

[Grigory Milev]

>>>>> "Valery" == Valery V Inozemtsev <shrek@progroup.ru> writes:

    Valery> <skip>
    >> возможный вариант, но тогда postfix-sasl должен собираться со всеми
    >> опциями, которые есть сейчас в postfix???

    Valery> угу

    >> и как sasl2 живет с postfix в chroot'е?

    Valery> у меня вот так:

    Valery> /etc/sysconfig/saslauthd

    Valery> OPTIONS="-a pam -m /var/spool/postfix/var/run/saslauthd"
Аналогично, может кто-нить что-нить поизящнее предложит?

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

Re: [devel] Python Modules Policy: (was: alternatives && postfix)

[Alexey Morozov]

On Tue, Feb 10, 2004 at 12:19:10PM +0300, Алексей Любимов wrote:
> оверхед уж больно большой. Изначальный трехстрочный спек уж больно 
> мутным получается.
> Лучше тогда скрипт наваять для генерации  спеков для разных питонов из 
> одного исходного...
Не вопрос. Мы с Андреем уже договорились (в джаббере) до того, что

1. Он проставляет Obsoletes: pythonN в python{N+1} или делает
   аналогичные изменения, о точном решении будет сообщено
   дополнительно ориентировочно в конце недели.
2. _Одновременная_ сборка пакетов под разные версии питона является
   на данный момент ненужной ввиду своей трудоемкости.
3. Андрей думает над целесообразностью сборки пакетов вида
   python<N>-ModuleName из исходника вида python-ModuleName
4. Я выкладываю на woland свой текущий вариант спеков, попутно
   думая над "полезными макросами"
5. В полиси для питоньих модулей вносится обязательный
   Requires: python = %<pversion>, где %<pversion> совпадает с
   %__python_version того питона, для которого производилась сборка.

Предлагается подумать над следующими двумя полиси:
6. Программы на python, не зависящие от конкретной версии питона
   (epydoc, python-doc-tools), собираются _без_ байткода и,
   соответственно, без привязки к точной версии питона, используется
   #!/usr/bin/env python ...
7. Программы, имеющие такую привязку (н-р, идущие вместе с конкретной
   версией питона) иcпользуют #!/usr/bin/env python<version> ...
   и могут таскать за собой байткод.
8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать
   только байткод, а .py заворачивать в отдельные пакеты "для
   интересующихся" (по моему разумению, по схеме, напоминающей то, что
   делает Алекс Отт для емакса, хотя _это мои предположения_)

Re: [devel] Python Modules Policy: (was: alternatives && postfix)

[Alexey Morozov]

On Tue, Feb 10, 2004 at 12:19:10PM +0300, Алексей Любимов wrote:
> оверхед уж больно большой. Изначальный трехстрочный спек уж больно 
> мутным получается.
> Лучше тогда скрипт наваять для генерации  спеков для разных питонов из 
> одного исходного...
Не вопрос. Мы с Андреем уже договорились (в джаббере) до того, что

1. Он проставляет Obsoletes: pythonN в python{N+1} или делает
   аналогичные изменения, о точном решении будет сообщено
   дополнительно ориентировочно в конце недели.
2. _Одновременная_ сборка пакетов под разные версии питона является
   на данный момент ненужной ввиду своей трудоемкости.
3. Андрей думает над целесообразностью сборки пакетов вида
   python<N>-ModuleName из исходника вида python-ModuleName
4. Я выкладываю на woland свой текущий вариант спеков, попутно
   думая над "полезными макросами"
5. В полиси для питоньих модулей вносится обязательный
   Requires: python = %<pversion>, где %<pversion> совпадает с
   %__python_version того питона, для которого производилась сборка.

Предлагается подумать над следующими двумя полиси:
6. Программы на python, не зависящие от конкретной версии питона
   (epydoc, python-doc-tools), собираются _без_ байткода и,
   соответственно, без привязки к точной версии питона, используется
   #!/usr/bin/env python ...
7. Программы, имеющие такую привязку (н-р, идущие вместе с конкретной
   версией питона) иcпользуют #!/usr/bin/env python<version> ...
   и могут таскать за собой байткод.
8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать
   только байткод, а .py заворачивать в отдельные пакеты "для
   интересующихся" (по моему разумению, по схеме, напоминающей то, что
   делает Алекс Отт для емакса, хотя _это мои предположения_)

Re: [devel] Re: alternatives && postfix

[Egor S. Orlov]

On Tue, 10 Feb 2004 11:51:13 +0200
Michael Shigorin <mike@osdn.org.ua> wrote:

> On Tue, Feb 10, 2004 at 12:20:13PM +0300, Egor S. Orlov wrote:
> > > > grep: /usr/lib/libgtk-x11-2.0.la: No such file or directory
> > > rpm -q libtool_1.5
> > libtool_1.5-1.5-alt11
> > по совету Юрия пересобрал gtkglarea без la проблемма была в ней
> > если maintener (aen) будет не против - залью все в incoming
> 
> Добудьте для начала 1.5.2.
> 

и с ней таже петрушка,
пакеты готовы, можно их заливать.

Только хотелось бы дождаться
финального мнения(выше по треду) всех заинтересованных лиц
по поводу правильного проставления зависимости на python.

-- 
WBR, Egor S. Orlov
FST SPbSPU

Re: [devel] Re: alternatives && postfix

[Egor S. Orlov]

On Tue, 10 Feb 2004 11:51:13 +0200
Michael Shigorin <mike@osdn.org.ua> wrote:

> On Tue, Feb 10, 2004 at 12:20:13PM +0300, Egor S. Orlov wrote:
> > > > grep: /usr/lib/libgtk-x11-2.0.la: No such file or directory
> > > rpm -q libtool_1.5
> > libtool_1.5-1.5-alt11
> > по совету Юрия пересобрал gtkglarea без la проблемма была в ней
> > если maintener (aen) будет не против - залью все в incoming
> 
> Добудьте для начала 1.5.2.
> 

и с ней таже петрушка,
пакеты готовы, можно их заливать.

Только хотелось бы дождаться
финального мнения(выше по треду) всех заинтересованных лиц
по поводу правильного проставления зависимости на python.

-- 
WBR, Egor S. Orlov
FST SPbSPU

Re: [devel] Re: alternatives && postfix

[Yuri N. Sedunov]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1112 bytes --]

On 10 Февраль 2004 12:51, Michael Shigorin wrote:
> On Tue, Feb 10, 2004 at 12:20:13PM +0300, Egor S. Orlov wrote:
> > > > grep: /usr/lib/libgtk-x11-2.0.la: No such file or directory
> > >
> > > rpm -q libtool_1.5
> >
> > libtool_1.5-1.5-alt11
> > по совету Юрия пересобрал gtkglarea без la проблемма была в ней
> > если maintener (aen) будет не против - залью все в incoming

AEN наверняка не против.

> Добудьте для начала 1.5.2.

И чуда не произошло.

[aris@altair SPECS]$ rpm -q libtool_1.5
libtool_1.5-1.5.2-alt1
[aris@altair SPECS]$ rpmbi pygtk.spec
.....
/bin/sed: can't read /usr/lib/libgtk-x11-2.0.la: No such file or directory
libtool: link: `/usr/lib/libgtk-x11-2.0.la' is not a valid libtool archive
make[2]: *** [gl.la] Error 1
make[2]: Leaving directory `/home/aris/RPM/BUILD/pygtk-2.0.0/gtk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/aris/RPM/BUILD/pygtk-2.0.0'
make: *** [all] Error 2
make: Leaving directory `/home/aris/RPM/BUILD/pygtk-2.0.0'
error: Bad exit status from /home/aris/RPM/TMP/rpm-tmp.77079 (%build)

-- 
Yuri N. Sedunov

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

Re: [devel] Re: alternatives && postfix

[Yuri N. Sedunov]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1112 bytes --]

On 10 Февраль 2004 12:51, Michael Shigorin wrote:
> On Tue, Feb 10, 2004 at 12:20:13PM +0300, Egor S. Orlov wrote:
> > > > grep: /usr/lib/libgtk-x11-2.0.la: No such file or directory
> > >
> > > rpm -q libtool_1.5
> >
> > libtool_1.5-1.5-alt11
> > по совету Юрия пересобрал gtkglarea без la проблемма была в ней
> > если maintener (aen) будет не против - залью все в incoming

AEN наверняка не против.

> Добудьте для начала 1.5.2.

И чуда не произошло.

[aris@altair SPECS]$ rpm -q libtool_1.5
libtool_1.5-1.5.2-alt1
[aris@altair SPECS]$ rpmbi pygtk.spec
.....
/bin/sed: can't read /usr/lib/libgtk-x11-2.0.la: No such file or directory
libtool: link: `/usr/lib/libgtk-x11-2.0.la' is not a valid libtool archive
make[2]: *** [gl.la] Error 1
make[2]: Leaving directory `/home/aris/RPM/BUILD/pygtk-2.0.0/gtk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/aris/RPM/BUILD/pygtk-2.0.0'
make: *** [all] Error 2
make: Leaving directory `/home/aris/RPM/BUILD/pygtk-2.0.0'
error: Bad exit status from /home/aris/RPM/TMP/rpm-tmp.77079 (%build)

-- 
Yuri N. Sedunov

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

Re: [devel] Re: alternatives && postfix

[Egor S. Orlov]

новые сборки 
pygtk2
pyorbit
gtkglarea2

ушли в incoming



On Mon, 9 Feb 2004 18:04:03 +0300
"Yuri N. Sedunov" <aris@altlinux.ru> wrote:

> On 9 Февраль 2004 17:45, Алексей Любимов wrote:
> > Michael Shigorin пишет:
> > >On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
> > >>сизиф и "серверная почтовая программа"?  Это серьезно?
> > >
> > >Это серьезнее, чем:
> >
> > не думаю.
> > только сегодня пересобрал pygtk2. 
> 
> Почему нет багрепорта на pygtk2?
> Где лежит?
> 2oes: не могли бы Вы сравнить свою сборку и avl и сообщить, действительно ли 
> это так.
> 
> > в сизифе он оказался нерабочий...
> > тоже самое есть и будет с любой программой в сизифе.
> 
> -- 
> Yuri N. Sedunov


-- 
WBR, Egor S. Orlov
FST SPbSPU

Re: [devel] Re: alternatives && postfix

[Egor S. Orlov]

новые сборки 
pygtk2
pyorbit
gtkglarea2

ушли в incoming



On Mon, 9 Feb 2004 18:04:03 +0300
"Yuri N. Sedunov" <aris@altlinux.ru> wrote:

> On 9 Февраль 2004 17:45, Алексей Любимов wrote:
> > Michael Shigorin пишет:
> > >On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
> > >>сизиф и "серверная почтовая программа"?  Это серьезно?
> > >
> > >Это серьезнее, чем:
> >
> > не думаю.
> > только сегодня пересобрал pygtk2. 
> 
> Почему нет багрепорта на pygtk2?
> Где лежит?
> 2oes: не могли бы Вы сравнить свою сборку и avl и сообщить, действительно ли 
> это так.
> 
> > в сизифе он оказался нерабочий...
> > тоже самое есть и будет с любой программой в сизифе.
> 
> -- 
> Yuri N. Sedunov


-- 
WBR, Egor S. Orlov
FST SPbSPU

Re: [devel] Python Modules Policy:

[Алексей Любимов]

>Не вопрос. Мы с Андреем уже договорились (в джаббере) до того, что
>
>1. Он проставляет Obsoletes: pythonN в python{N+1} или делает
>   аналогичные изменения, о точном решении будет сообщено
>   дополнительно ориентировочно в конце недели.
>2. _Одновременная_ сборка пакетов под разные версии питона является
>   на данный момент ненужной ввиду своей трудоемкости.
>
реально это означает, что поддержка python22 отменяется.
Или, проще говоря, на зоп* в сизифе и все, что посложнее "hello world" 
можно забить.

>3. Андрей думает над целесообразностью сборки пакетов вида
>   python<N>-ModuleName из исходника вида python-ModuleName
>
Если будет строго выполнен пункт 2, то это имхо лишнее...
Уж если у кого дойдут руки, то можно делать пакеты python22-ModuleName
то есть схема пакет и compat-пакет, а не ПакетВерсия1 и ПакетВерсия2


>5. В полиси для питоньих модулей вносится обязательный
>   Requires: python = %<pversion>, где %<pversion> совпадает с
>   %__python_version того питона, для которого производилась сборка.
>
Это понятно.

>Предлагается подумать над следующими двумя полиси:
>6. Программы на python, не зависящие от конкретной версии питона
>   (epydoc, python-doc-tools), собираются _без_ байткода и,
>   соответственно, без привязки к точной версии питона, используется
>   #!/usr/bin/env python ...
>
А где же они лежать будут? по логике все равно в python?.?/site-packages/
По моему, это излишнее усложнение. Поддерживается один питон, так и 
пусть поддерживается.
Наоборот скорее от сорцов надо избавлятся (только без размножения пакетов).

>7. Программы, имеющие такую привязку (н-р, идущие вместе с конкретной
>   версией питона) иcпользуют #!/usr/bin/env python<version> ...
>   и могут таскать за собой байткод.
>
В скриптах? и вы согласны переписывать все скрипты в модуле при переходе 
версий???

>8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать
>   только байткод, а .py заворачивать в отдельные пакеты "для
>   интересующихся" (по моему разумению, по схеме, напоминающей то, что
>   делает Алекс Отт для емакса, хотя _это мои предположения_)
>
И наплодить еще дубликатов-пакетов пачку.

У меня вот зреет какое то общее средство под кодовым названием stripper.
В пакеты кладутся схемы файлов в виде регэкспов.
Также пишуться глобальные регэкспы типа __nodoc__  = /usr/share/doc/.*
__noman__ =  /usr/share/man/.* /.*

__nopy_source__ = *.py

__nopy_pyc__ = *.pyc


В любой момент, включая установку пакета, можно вызвать stripper 
пакет(ы) и он обрежет по правилам файлы и перенесет их в архив или 
вернет обратно.
Также можно поставить правила по умолчанию и они будут срабатывать при 
установке пакетов сами.

Незрело, конечно, но по моему, вполне может получится...

Re: [devel] Python Modules Policy:

[Алексей Любимов]

>Не вопрос. Мы с Андреем уже договорились (в джаббере) до того, что
>
>1. Он проставляет Obsoletes: pythonN в python{N+1} или делает
>   аналогичные изменения, о точном решении будет сообщено
>   дополнительно ориентировочно в конце недели.
>2. _Одновременная_ сборка пакетов под разные версии питона является
>   на данный момент ненужной ввиду своей трудоемкости.
>
реально это означает, что поддержка python22 отменяется.
Или, проще говоря, на зоп* в сизифе и все, что посложнее "hello world" 
можно забить.

>3. Андрей думает над целесообразностью сборки пакетов вида
>   python<N>-ModuleName из исходника вида python-ModuleName
>
Если будет строго выполнен пункт 2, то это имхо лишнее...
Уж если у кого дойдут руки, то можно делать пакеты python22-ModuleName
то есть схема пакет и compat-пакет, а не ПакетВерсия1 и ПакетВерсия2


>5. В полиси для питоньих модулей вносится обязательный
>   Requires: python = %<pversion>, где %<pversion> совпадает с
>   %__python_version того питона, для которого производилась сборка.
>
Это понятно.

>Предлагается подумать над следующими двумя полиси:
>6. Программы на python, не зависящие от конкретной версии питона
>   (epydoc, python-doc-tools), собираются _без_ байткода и,
>   соответственно, без привязки к точной версии питона, используется
>   #!/usr/bin/env python ...
>
А где же они лежать будут? по логике все равно в python?.?/site-packages/
По моему, это излишнее усложнение. Поддерживается один питон, так и 
пусть поддерживается.
Наоборот скорее от сорцов надо избавлятся (только без размножения пакетов).

>7. Программы, имеющие такую привязку (н-р, идущие вместе с конкретной
>   версией питона) иcпользуют #!/usr/bin/env python<version> ...
>   и могут таскать за собой байткод.
>
В скриптах? и вы согласны переписывать все скрипты в модуле при переходе 
версий???

>8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать
>   только байткод, а .py заворачивать в отдельные пакеты "для
>   интересующихся" (по моему разумению, по схеме, напоминающей то, что
>   делает Алекс Отт для емакса, хотя _это мои предположения_)
>
И наплодить еще дубликатов-пакетов пачку.

У меня вот зреет какое то общее средство под кодовым названием stripper.
В пакеты кладутся схемы файлов в виде регэкспов.
Также пишуться глобальные регэкспы типа __nodoc__  = /usr/share/doc/.*
__noman__ =  /usr/share/man/.* /.*

__nopy_source__ = *.py

__nopy_pyc__ = *.pyc


В любой момент, включая установку пакета, можно вызвать stripper 
пакет(ы) и он обрежет по правилам файлы и перенесет их в архив или 
вернет обратно.
Также можно поставить правила по умолчанию и они будут срабатывать при 
установке пакетов сами.

Незрело, конечно, но по моему, вполне может получится...

Re: [devel] Re: alternatives && postfix

[Anton Farygin]

On Tue, Feb 10, 2004 at 11:28:52AM +0300, Andrey Orlov wrote:
> On Tuesday 10 February 2004 11:04, Alexey Morozov wrote:
> > <flame>
> > Даешь по четыре машины на каждого девелупера! Им ведь с этим кодом
> > _работать_ надо, а не просто смотреть на его [не]работоспособность.
> > А работа - это не просто pythonX и pyPackageY, pyPackageZ итп. Это еще и
> > те либы, которые цепляются в проекте, и возможность проверять код в
> > своем _привычном_ девелоперском окружении (читай: из редактора) итп.
> > </flame>
> 
> У меня три среды - для сборки под master22, ASP, и сизифа - стоят на одной машине
> и доступны _одновременно_. И так уже не первый год. Я совершенно спокойно
> работаю и это не вызывает ровным счетом никаких проблем. Почитайте man chroot.
> Пару раз ко мне обращались люди, которым нужна была среда для сборки под сизиф, 
> а сами они работали либо в редхэт, либо в asp - я им об этом рассказал и у них это тоже
> сработало. Попробуйте и вы, это действително нетрудна.
> 
> Кстати, на самом деле у меня даже два сизифа - вчерашний и сегодняшний. Если апгрейд
> сегодняшнего до завтрашнего приводит к проблемам, я перегружаюсь во вчерашний.
> Но, тут уже нужна перезагрузка, правда, такие проблемы возникают редко.

Еще можно сказать apt-get install kernel-image-vs-smp и получить себе
возможность делать виртуальные сервера.

Rgds,
Rider

Re: [devel] Re: alternatives && postfix

[Anton Farygin]

On Tue, Feb 10, 2004 at 11:28:52AM +0300, Andrey Orlov wrote:
> On Tuesday 10 February 2004 11:04, Alexey Morozov wrote:
> > <flame>
> > Даешь по четыре машины на каждого девелупера! Им ведь с этим кодом
> > _работать_ надо, а не просто смотреть на его [не]работоспособность.
> > А работа - это не просто pythonX и pyPackageY, pyPackageZ итп. Это еще и
> > те либы, которые цепляются в проекте, и возможность проверять код в
> > своем _привычном_ девелоперском окружении (читай: из редактора) итп.
> > </flame>
> 
> У меня три среды - для сборки под master22, ASP, и сизифа - стоят на одной машине
> и доступны _одновременно_. И так уже не первый год. Я совершенно спокойно
> работаю и это не вызывает ровным счетом никаких проблем. Почитайте man chroot.
> Пару раз ко мне обращались люди, которым нужна была среда для сборки под сизиф, 
> а сами они работали либо в редхэт, либо в asp - я им об этом рассказал и у них это тоже
> сработало. Попробуйте и вы, это действително нетрудна.
> 
> Кстати, на самом деле у меня даже два сизифа - вчерашний и сегодняшний. Если апгрейд
> сегодняшнего до завтрашнего приводит к проблемам, я перегружаюсь во вчерашний.
> Но, тут уже нужна перезагрузка, правда, такие проблемы возникают редко.

Еще можно сказать apt-get install kernel-image-vs-smp и получить себе
возможность делать виртуальные сервера.

Rgds,
Rider

Re: [devel] Python Modules Policy:

[Andrey Orlov]

В сообщении от Вторник 10 Февраль 2004 18:51 Алексей Любимов написал:
> реально это означает, что поддержка python22 отменяется.
> Или, проще говоря, на зоп* в сизифе и все, что посложнее "hello world"
> можно забить.

С чего вы так решили? Zope из сизифа, пересобранный с python23, работает
на коммерческом хостинге уже больше месяца, с очень высокой нагрузкой. 

> >8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать
> У меня вот зреет какое то общее средство под кодовым названием stripper.

При этом содержимое rpmdb не будет соответствовать содержимому файловой 
системы? Тогда уж проще воспользоваться опциями rpm типа exclude, чем кодовое
средство городить.

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

Re: [devel] Python Modules Policy:

[Andrey Orlov]

В сообщении от Вторник 10 Февраль 2004 18:51 Алексей Любимов написал:
> реально это означает, что поддержка python22 отменяется.
> Или, проще говоря, на зоп* в сизифе и все, что посложнее "hello world"
> можно забить.

С чего вы так решили? Zope из сизифа, пересобранный с python23, работает
на коммерческом хостинге уже больше месяца, с очень высокой нагрузкой. 

> >8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать
> У меня вот зреет какое то общее средство под кодовым названием stripper.

При этом содержимое rpmdb не будет соответствовать содержимому файловой 
системы? Тогда уж проще воспользоваться опциями rpm типа exclude, чем кодовое
средство городить.

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

Re: [devel] Python Modules Policy:

[Алексей Любимов]

Andrey Orlov пишет:

>В сообщении от Вторник 10 Февраль 2004 18:51 Алексей Любимов написал:
>  
>
>>реально это означает, что поддержка python22 отменяется.
>>Или, проще говоря, на зоп* в сизифе и все, что посложнее "hello world"
>>можно забить.
>>    
>>
>
>С чего вы так решили? Zope из сизифа, пересобранный с python23, работает
>на коммерческом хостинге уже больше месяца, с очень высокой нагрузкой. 
>  
>
в сизифе ничего окромя зопа по большому счету и нет.
Там где есть возможность пересобрать весь набор зопа и так все хорошо.


>  
>
>>>8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать
>>>      
>>>
>>У меня вот зреет какое то общее средство под кодовым названием stripper.
>>    
>>
>
>При этом содержимое rpmdb не будет соответствовать содержимому файловой 
>системы?
>
Не то, чтобы совсем несоответствовать. Оно будет его максимальным 
множеством. "левых" в файловой системе не будет.
В идеале rpm можно научить лазить в "карман" за убраными файлами. Типа 
как фпт лазиет в /var/cache/apt прежде чем качать пакеты.

> Тогда уж проще воспользоваться опциями rpm типа exclude, чем кодовое
>средство городить.
>
Возможно. только опции, это опции, а динамически применяемые маски и 
каскадируемые регэекспы, это совсем другой подход.

Re: [devel] Python Modules Policy:

[Алексей Любимов]

Andrey Orlov пишет:

>В сообщении от Вторник 10 Февраль 2004 18:51 Алексей Любимов написал:
>  
>
>>реально это означает, что поддержка python22 отменяется.
>>Или, проще говоря, на зоп* в сизифе и все, что посложнее "hello world"
>>можно забить.
>>    
>>
>
>С чего вы так решили? Zope из сизифа, пересобранный с python23, работает
>на коммерческом хостинге уже больше месяца, с очень высокой нагрузкой. 
>  
>
в сизифе ничего окромя зопа по большому счету и нет.
Там где есть возможность пересобрать весь набор зопа и так все хорошо.


>  
>
>>>8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать
>>>      
>>>
>>У меня вот зреет какое то общее средство под кодовым названием stripper.
>>    
>>
>
>При этом содержимое rpmdb не будет соответствовать содержимому файловой 
>системы?
>
Не то, чтобы совсем несоответствовать. Оно будет его максимальным 
множеством. "левых" в файловой системе не будет.
В идеале rpm можно научить лазить в "карман" за убраными файлами. Типа 
как фпт лазиет в /var/cache/apt прежде чем качать пакеты.

> Тогда уж проще воспользоваться опциями rpm типа exclude, чем кодовое
>средство городить.
>
Возможно. только опции, это опции, а динамически применяемые маски и 
каскадируемые регэекспы, это совсем другой подход.

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 17:14, Egor S. Orlov wrote:
> pygtk2
> pyorbit
> gtkglarea2
>
> ушли в incoming

Спасибо

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

Re: [devel] Re: alternatives && postfix

[Andrey Orlov]

On Tuesday 10 February 2004 17:14, Egor S. Orlov wrote:
> pygtk2
> pyorbit
> gtkglarea2
>
> ушли в incoming

Спасибо

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

[devel] Administrativia

[Dmitry V. Levin]

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

Коллеги,

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

Господа avl@ и mike@, вы действительно хотите, чтобы ваши постинги в этот
список проходили через обязательный approval?

Не разрушайте рабочую обстановку, пожалуйста.

On Mon, Feb 09, 2004 at 04:20:24PM +0200, Michael Shigorin wrote:
> On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
> > сизиф и "серверная почтовая программа"?  Это серьезно?
> 
> Это серьезнее, чем:
> 
> > ps в репозитариях linux-os.ru лежат сборки постфикса с sasl2 и
> > mysql и courier-imap для мастера и сизифа.
> 
> по очевидной причине: сизиф когда-нибудь да становится блинами.


-- 
ldv

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

[devel] Administrativia

[Dmitry V. Levin]

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

Коллеги,

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

Господа avl@ и mike@, вы действительно хотите, чтобы ваши постинги в этот
список проходили через обязательный approval?

Не разрушайте рабочую обстановку, пожалуйста.

On Mon, Feb 09, 2004 at 04:20:24PM +0200, Michael Shigorin wrote:
> On Mon, Feb 09, 2004 at 05:03:10PM +0300, Алексей Любимов wrote:
> > сизиф и "серверная почтовая программа"?  Это серьезно?
> 
> Это серьезнее, чем:
> 
> > ps в репозитариях linux-os.ru лежат сборки постфикса с sasl2 и
> > mysql и courier-imap для мастера и сизифа.
> 
> по очевидной причине: сизиф когда-нибудь да становится блинами.


-- 
ldv

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

Re: [devel] alternatives && postfix

[Dmitry V. Levin]

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

Hi,

On Mon, Feb 09, 2004 at 02:47:10PM +0200, Grigory Milev wrote:
>    Вопрос уже поднимался, но, что-то без результат но!!!
> Собственно речь идет о сборке postfix с sasl2. Для этого в Sisyphus есть все,
> кроме желания по дефолту иметь postfix собранный с вышеуказанной
> библиотекой. Отсутствие собранного с ней postfix сильно подкашивает возможность
> его использования как серверной почтовой программы, а так же как программы для
> отсылки почты через smtp сервера с авторизацией.
>   Собственно есть предложение собрать postfix-sasl или что-то подобное и
> переключать его через альтернативы. Единственное но, как через альтернативы
> переключать /etc/chroot.d/postfix.lib и, кто этим займется?

А почему через альтернативы?


-- 
ldv

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

Re: [devel] alternatives && postfix

[Dmitry V. Levin]

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

Hi,

On Mon, Feb 09, 2004 at 02:47:10PM +0200, Grigory Milev wrote:
>    Вопрос уже поднимался, но, что-то без результат но!!!
> Собственно речь идет о сборке postfix с sasl2. Для этого в Sisyphus есть все,
> кроме желания по дефолту иметь postfix собранный с вышеуказанной
> библиотекой. Отсутствие собранного с ней postfix сильно подкашивает возможность
> его использования как серверной почтовой программы, а так же как программы для
> отсылки почты через smtp сервера с авторизацией.
>   Собственно есть предложение собрать postfix-sasl или что-то подобное и
> переключать его через альтернативы. Единственное но, как через альтернативы
> переключать /etc/chroot.d/postfix.lib и, кто этим займется?

А почему через альтернативы?


-- 
ldv

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

Re: [devel] Python Modules Policy:

[Andrey Orlov]

On Tuesday 10 February 2004 21:28, Алексей Любимов wrote:
> >С чего вы так решили? Zope из сизифа, пересобранный с python23, работает
> >на коммерческом хостинге уже больше месяца, с очень высокой нагрузкой.
>
> в сизифе ничего окромя зопа по большому счету и нет.

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

> >При этом содержимое rpmdb не будет соответствовать содержимому файловой
> >системы?
>
> Не то, чтобы совсем несоответствовать. Оно будет его максимальным
> множеством. "левых" в файловой системе не будет.

Но verify даст кучу ошибок....

> > Тогда уж проще воспользоваться опциями rpm типа exclude, чем кодовое
> >средство городить.
> Возможно. только опции, это опции, а динамически применяемые маски и
> каскадируемые регэекспы, это совсем другой подход.

exclude - это и есть динамически применямая маска, только файл еще и не прописывается в rpmdb.

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

Re: [devel] Python Modules Policy:

[Andrey Orlov]

On Tuesday 10 February 2004 21:28, Алексей Любимов wrote:
> >С чего вы так решили? Zope из сизифа, пересобранный с python23, работает
> >на коммерческом хостинге уже больше месяца, с очень высокой нагрузкой.
>
> в сизифе ничего окромя зопа по большому счету и нет.

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

> >При этом содержимое rpmdb не будет соответствовать содержимому файловой
> >системы?
>
> Не то, чтобы совсем несоответствовать. Оно будет его максимальным
> множеством. "левых" в файловой системе не будет.

Но verify даст кучу ошибок....

> > Тогда уж проще воспользоваться опциями rpm типа exclude, чем кодовое
> >средство городить.
> Возможно. только опции, это опции, а динамически применяемые маски и
> каскадируемые регэекспы, это совсем другой подход.

exclude - это и есть динамически применямая маска, только файл еще и не прописывается в rpmdb.

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

Re: [devel] alternatives && postfix

[Grigory Milev]

>>>>> "Dmitry" == Dmitry V Levin <ldv@altlinux.org> writes:
    >> библиотекой. Отсутствие собранного с ней postfix сильно подкашивает
    >> возможность его использования как серверной почтовой программы, а так
    >> же как программы для отсылки почты через smtp сервера с авторизацией.
    >> Собственно есть предложение собрать postfix-sasl или что-то подобное и
    >> переключать его через альтернативы. Единственное но, как через
    >> альтернативы переключать /etc/chroot.d/postfix.lib и, кто этим
    >> займется?

    Dmitry> А почему через альтернативы?
Да как-то первое, что пришло в голову. Собственно вполне устроит наличие двух
сборок постфикса в сизифе. Если господа не против, я соберу постфикс с sasl2.

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

Re: [devel] alternatives && postfix

[Grigory Milev]

>>>>> "Dmitry" == Dmitry V Levin <ldv@altlinux.org> writes:
    >> библиотекой. Отсутствие собранного с ней postfix сильно подкашивает
    >> возможность его использования как серверной почтовой программы, а так
    >> же как программы для отсылки почты через smtp сервера с авторизацией.
    >> Собственно есть предложение собрать postfix-sasl или что-то подобное и
    >> переключать его через альтернативы. Единственное но, как через
    >> альтернативы переключать /etc/chroot.d/postfix.lib и, кто этим
    >> займется?

    Dmitry> А почему через альтернативы?
Да как-то первое, что пришло в голову. Собственно вполне устроит наличие двух
сборок постфикса в сизифе. Если господа не против, я соберу постфикс с sasl2.

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

Re: [devel] Python Modules Policy:

[Alexey Morozov]

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

On Tue, Feb 10, 2004 at 06:51:18PM +0300, Алексей Любимов wrote:
> 
> >Не вопрос. Мы с Андреем уже договорились (в джаббере) до того, что
> >
> >1. Он проставляет Obsoletes: pythonN в python{N+1} или делает
> >  аналогичные изменения, о точном решении будет сообщено
> >  дополнительно ориентировочно в конце недели.
> >2. _Одновременная_ сборка пакетов под разные версии питона является
> >  на данный момент ненужной ввиду своей трудоемкости.
> реально это означает, что поддержка python22 отменяется.
> Или, проще говоря, на зоп* в сизифе и все, что посложнее "hello world" 
> можно забить.
Нет. Их можно будет собирать "неодновременно", т.е. в два прохода.
Может быть, даже автоматом.


> >3. Андрей думает над целесообразностью сборки пакетов вида
> >  python<N>-ModuleName из исходника вида python-ModuleName
> Если будет строго выполнен пункт 2, то это имхо лишнее...
> Уж если у кого дойдут руки, то можно делать пакеты python22-ModuleName
> то есть схема пакет и compat-пакет, а не ПакетВерсия1 и ПакетВерсия2
См. выше про автомат.

> >5. В полиси для питоньих модулей вносится обязательный
> >  Requires: python = %<pversion>, где %<pversion> совпадает с
> >  %__python_version того питона, для которого производилась сборка.
> Это понятно.
ldv@ уже предложил решение, которое, вроде бы, не хуже по последствиям,
но автоматизируется. Прокомментируйте его, пожалуйста.


> >Предлагается подумать над следующими двумя полиси:
> >6. Программы на python, не зависящие от конкретной версии питона
> >  (epydoc, python-doc-tools), собираются _без_ байткода и,
> >  соответственно, без привязки к точной версии питона, используется
> >  #!/usr/bin/env python ...
> А где же они лежать будут? по логике все равно в python?.?/site-packages/
Нет. Питоньи скрипты (н-р, python-doc-tools) лежат не там.
epydoc тоже лежит не там, вроде бы. Если нужно подумать над
"версионно-независимом" каталоге для питона, его можно организовать,
насколько я понимаю.


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


> >7. Программы, имеющие такую привязку (н-р, идущие вместе с конкретной
> >  версией питона) иcпользуют #!/usr/bin/env python<version> ...
> >  и могут таскать за собой байткод.
> В скриптах? и вы согласны переписывать все скрипты в модуле при переходе 
> версий???
Если эти _скрипты_ завязаны на данную версию питона: да, согласен.
Но, мой опыт (сборки twisted) показывает, что достаточно внятно разделить:
вот этот пакет - модул{ь,и}, он[и] привязан[ы] к версии питона, а вот
это - скрипты [из /usr/bin], которые одинаково хорошо работают как с
твистедом, собранным под 2.2, так и с твистедом, собранным под 2.3

> >8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать
> >  только байткод, а .py заворачивать в отдельные пакеты "для
> >  интересующихся" (по моему разумению, по схеме, напоминающей то, что
> >  делает Алекс Отт для емакса, хотя _это мои предположения_)
> И наплодить еще дубликатов-пакетов пачку.
У Андрея были практические соображения, почему в боевую версию НЕ надо
пихать сорцы. С другой стороны, мой небольшой практический опыт
показывает, что сорцы _иногда_ нужны.

> У меня вот зреет какое то общее средство под кодовым названием stripper.
...
> Также можно поставить правила по умолчанию и они будут срабатывать при 
> установке пакетов сами.
Это никак не упихивается в рамки distutils?

> 
> Незрело, конечно, но по моему, вполне может получится...
Показывайте.


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

Re: [devel] alternatives && postfix

[Alexei Takaseev]

On Wed, 11 Feb 2004 10:48:00 +0200
Grigory Milev <week@altlinux.ru> wrote:

> >>>>> "Dmitry" == Dmitry V Levin <ldv@altlinux.org> writes:
>     >> библиотекой. Отсутствие собранного с ней postfix сильно
>     >подкашивает> возможность его использования как серверной почтовой
>     >программы, а так> же как программы для отсылки почты через smtp
>     >сервера с авторизацией.> Собственно есть предложение собрать
>     >postfix-sasl или что-то подобное и> переключать его через
>     >альтернативы. Единственное но, как через> альтернативы
>     >переключать /etc/chroot.d/postfix.lib и, кто этим> займется?
> 
>     Dmitry> А почему через альтернативы?
> Да как-то первое, что пришло в голову. Собственно вполне устроит
> наличие двух сборок постфикса в сизифе. Если господа не против, я
> соберу постфикс с sasl2.

ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Daedalus/SRPMS.daedalus/postfix-2.0.18-alt1.2.src.rpm

:)

Re: [devel] alternatives && postfix

[Grigory Milev]

>>>>> "Alexei" == Alexei Takaseev <taf@altlinux.ru> writes:
    Dmitry> А почему через альтернативы?
    >> Да как-то первое, что пришло в голову. Собственно вполне устроит
    >> наличие двух сборок постфикса в сизифе. Если господа не против, я
    >> соберу постфикс с sasl2.

    Alexei> ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Daedalus/SRPMS.daedalus/postfix-2.0.18-alt1.2.src.rpm

Для себя я его уже собрал.
К стати, зачем в указанном выше postfix'е добавлен патч для IPV6? У меня все
замечательно работает без изменения/добавления патчей. Для сборки postfix с
sasl достаточно в спеке поправить BuildReq и подправить chroot.d/postfix.lib.

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

Re: [devel] alternatives && postfix

[Grigory Milev]

>>>>> "Alexei" == Alexei Takaseev <taf@altlinux.ru> writes:
    Dmitry> А почему через альтернативы?
    >> Да как-то первое, что пришло в голову. Собственно вполне устроит
    >> наличие двух сборок постфикса в сизифе. Если господа не против, я
    >> соберу постфикс с sasl2.

    Alexei> ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Daedalus/SRPMS.daedalus/postfix-2.0.18-alt1.2.src.rpm

Для себя я его уже собрал.
К стати, зачем в указанном выше postfix'е добавлен патч для IPV6? У меня все
замечательно работает без изменения/добавления патчей. Для сборки postfix с
sasl достаточно в спеке поправить BuildReq и подправить chroot.d/postfix.lib.

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

Re: [devel] alternatives && postfix

[Alexei Takaseev]

On Wed, 11 Feb 2004 14:44:24 +0200
Grigory Milev <week@altlinux.ru> wrote:

> >>>>> "Alexei" == Alexei Takaseev <taf@altlinux.ru> writes:
>     Dmitry> А почему через альтернативы?
>     >> Да как-то первое, что пришло в голову. Собственно вполне
>     >устроит> наличие двух сборок постфикса в сизифе. Если господа не
>     >против, я> соберу постфикс с sasl2.
> 
>     Alexei>
>     ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Daedalus/SRPMS.daedalus/postfix-2.0.18-alt1.2.src.rpm
> 
> Для себя я его уже собрал.
> К стати, зачем в указанном выше postfix'е добавлен патч для IPV6? У
> меня все замечательно работает без изменения/добавления патчей. Для
> сборки postfix с sasl достаточно в спеке поправить BuildReq и
> подправить chroot.d/postfix.lib.

помимо IPv6 там добавляется такая полезная вещь как SSL/TLS.

Re: [devel] alternatives && postfix

[Grigory Milev]

>>>>> "Alexei" == Alexei Takaseev <taf@altlinux.ru> writes:
    >> ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Daedalus/SRPMS.daedalus/postfix-2.0.18-alt1.2.src.rpm
    >> 
    >> Для себя я его уже собрал.  К стати, зачем в указанном выше postfix'е
    >> добавлен патч для IPV6? У меня все замечательно работает без
    >> изменения/добавления патчей. Для сборки postfix с sasl достаточно в
    >> спеке поправить BuildReq и подправить chroot.d/postfix.lib.

    Alexei> помимо IPv6 там добавляется такая полезная вещь как SSL/TLS.
Разве без дополнительных патчей собрать postfix с поддержкой SSL/TLS нельзя?
он вроде должен уметь собираться с openssl.

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

Re: [devel] alternatives && postfix

[Grigory Milev]

>>>>> "Alexei" == Alexei Takaseev <taf@altlinux.ru> writes:
    >> ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Daedalus/SRPMS.daedalus/postfix-2.0.18-alt1.2.src.rpm
    >> 
    >> Для себя я его уже собрал.  К стати, зачем в указанном выше postfix'е
    >> добавлен патч для IPV6? У меня все замечательно работает без
    >> изменения/добавления патчей. Для сборки postfix с sasl достаточно в
    >> спеке поправить BuildReq и подправить chroot.d/postfix.lib.

    Alexei> помимо IPv6 там добавляется такая полезная вещь как SSL/TLS.
Разве без дополнительных патчей собрать postfix с поддержкой SSL/TLS нельзя?
он вроде должен уметь собираться с openssl.

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

Re: [devel] alternatives && postfix

[Alexei Takaseev]

On Wed, 11 Feb 2004 15:04:40 +0200
Grigory Milev <week@altlinux.ru> wrote:

> >>>>> "Alexei" == Alexei Takaseev <taf@altlinux.ru> writes:
>     >>
>     >ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Daedalus/SRPMS.
>     >daedalus/postfix-2.0.18-alt1.2.src.rpm> 
>     >> Для себя я его уже собрал.  К стати, зачем в указанном выше
>     >postfix'е> добавлен патч для IPV6? У меня все замечательно
>     >работает без> изменения/добавления патчей. Для сборки postfix с
>     >sasl достаточно в> спеке поправить BuildReq и подправить
>     >chroot.d/postfix.lib.
> 
>     Alexei> помимо IPv6 там добавляется такая полезная вещь как
>     SSL/TLS.
> Разве без дополнительных патчей собрать postfix с поддержкой SSL/TLS
> нельзя? он вроде должен уметь собираться с openssl.

Не умеет он этого делать, приходится допиливать.

[devel] Re: Python Modules Policy:

[Andrey Khavryuchenko]

Alexey,

"AM" == Alexey Morozov wrote:

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

Хм, а можно тем, кто эту дискуссию читает одним глазком напомнить эти
соображения? 

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

Re: [devel] alternatives && postfix

[Grigory Milev]

>>>>> "Alexei" == Alexei Takaseev <taf@altlinux.ru> writes:

    Alexei> On Wed, 11 Feb 2004 15:04:40 +0200
    Alexei> Grigory Milev <week@altlinux.ru> wrote:

    >> >>>>> "Alexei" == Alexei Takaseev <taf@altlinux.ru> writes:
    >> >>
    >> >ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Daedalus/SRPMS.
    >> >daedalus/postfix-2.0.18-alt1.2.src.rpm> >> Для себя я его уже собрал.
    >> К стати, зачем в указанном выше >postfix'е> добавлен патч для IPV6? У
    >> меня все замечательно >работает без> изменения/добавления патчей. Для
    >> сборки postfix с >sasl достаточно в> спеке поправить BuildReq и
    >> подправить >chroot.d/postfix.lib.
    >> 
    Alexei> помимо IPv6 там добавляется такая полезная вещь как
    >> SSL/TLS.  Разве без дополнительных патчей собрать postfix с поддержкой
    >> SSL/TLS нельзя? он вроде должен уметь собираться с openssl.
Тогда прийдется делать:
postfix-common
postfix
postfix-sasl
postfix-sasl-ssl

???

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

Re: [devel] alternatives && postfix

[vserge]

Добрый день

Вы написали Grigory Milev <week@altlinux.ru> Wed, 11 Feb 2004 15:54:38 +0200:

> >>>>> "Alexei" == Alexei Takaseev <taf@altlinux.ru> writes:
> 
>     Alexei> On Wed, 11 Feb 2004 15:04:40 +0200
>     Alexei> Grigory Milev <week@altlinux.ru> wrote:
> 
>     >> >>>>> "Alexei" == Alexei Takaseev <taf@altlinux.ru> writes:
>     >> >>
>     >> >ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Daedalus/SRPMS.
>     >> >daedalus/postfix-2.0.18-alt1.2.src.rpm> >> Для себя я его уже
>     >собрал.> К стати, зачем в указанном выше >postfix'е> добавлен патч для
>     >IPV6? У> меня все замечательно >работает без> изменения/добавления
>     >патчей. Для> сборки postfix с >sasl достаточно в> спеке поправить
>     >BuildReq и> подправить >chroot.d/postfix.lib.
>     >> 
>     Alexei> помимо IPv6 там добавляется такая полезная вещь как
>     >> SSL/TLS.  Разве без дополнительных патчей собрать postfix с
>     >поддержкой> SSL/TLS нельзя? он вроде должен уметь собираться с openssl.
> Тогда прийдется делать:
> postfix-common
> postfix
> postfix-sasl
> postfix-sasl-ssl
> 
тогда еще и postfix-ssl
-- 
Предлагаю прежде чем разрабатывать программу установки - написать
руководство пользователя по ней.
		-- rider in devel@

[devel] Muchos gracios

[Michael Shigorin]

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

On Wed, Feb 11, 2004 at 12:19:36AM +0300, Dmitry V. Levin wrote:
> пожалуйста, уважайте друг друга и следите за тем, чтобы смена
> содержания сообщений внутри треда сопровождалась сменой темы.

Согласен.

> Господа avl@ и mike@, вы действительно хотите, чтобы ваши
> постинги в этот список проходили через обязательный approval?
> Не разрушайте рабочую обстановку, пожалуйста.

Мне (и, полагаю, avl) проще в таком случае будет забить на этот
список со всеми вытекающими.

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

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

Re: [devel] alternatives && postfix

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

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

On Wed, Feb 11, 2004 at 03:54:38PM +0200, Grigory Milev wrote:

 > Тогда прийдется делать:
 > postfix-common
 > postfix
 > postfix-sasl
 > postfix-sasl-ssl
 > ???

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

http://dimline.ru/

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

Re: [devel] Python Modules Policy:

[Алексей Любимов]

Alexey Morozov пишет:

>On Tue, Feb 10, 2004 at 06:51:18PM +0300, Алексей Любимов wrote:
>  
>
>>>Не вопрос. Мы с Андреем уже договорились (в джаббере) до того, что
>>>
>>>1. Он проставляет Obsoletes: pythonN в python{N+1} или делает
>>> аналогичные изменения, о точном решении будет сообщено
>>> дополнительно ориентировочно в конце недели.
>>>2. _Одновременная_ сборка пакетов под разные версии питона является
>>> на данный момент ненужной ввиду своей трудоемкости.
>>>      
>>>
>>реально это означает, что поддержка python22 отменяется.
>>Или, проще говоря, на зоп* в сизифе и все, что посложнее "hello world" 
>>можно забить.
>>    
>>
>Нет. Их можно будет собирать "неодновременно", т.е. в два прохода.
>Может быть, даже автоматом.
>
А, так это в том смысле, что из одного спека за один проход собирать 
пакеты для всех питонов трудоемко?
Это как раз само собой разумеется.

Раз так, то на зоп в сизифе и все, что посложнее "hello world" можно (и 
нужно) не забивать :)


>  
>
>>>3. Андрей думает над целесообразностью сборки пакетов вида
>>> python<N>-ModuleName из исходника вида python-ModuleName
>>>      
>>>
>>Если будет строго выполнен пункт 2, то это имхо лишнее...
>>Уж если у кого дойдут руки, то можно делать пакеты python22-ModuleName
>>то есть схема пакет и compat-пакет, а не ПакетВерсия1 и ПакетВерсия2
>>    
>>
>См. выше про автомат.
>root, root
>
Теперь понятно.

>  
>
>>>5. В полиси для питоньих модулей вносится обязательный
>>> Requires: python = %<pversion>, где %<pversion> совпадает с
>>> %__python_version того питона, для которого производилась сборка.
>>>      
>>>
>>Это понятно.
>>    
>>
>ldv@ уже предложил решение, которое, вроде бы, не хуже по последствиям,
>но автоматизируется. Прокомментируйте его, пожалуйста.
>
Менять макросы rpmbuild?
По моему это источник еще одной головной боли.
Опять будет куча unmets, как это происходит при любом чихе сейчас с 
перлом и прочими.
Но самое главное, будет непрозрачное повдение rpm при сборке пакета.
Проблема с с зависимостями питона не так серьезна, чтобы рубить с плеча.
По моему все очень просто - поставил Requires: python = %<pversion> и 
получил нужную зависимость.
А не поставил - получил более свободный и универсальный вариант. Всем 
хорошо и никому плохо.

>>>Предлагается подумать над следующими двумя полиси:
>>>6. Программы на python, не зависящие от конкретной версии питона
>>> (epydoc, python-doc-tools), собираются _без_ байткода и,
>>> соответственно, без привязки к точной версии питона, используется
>>> #!/usr/bin/env python ...
>>>      
>>>
>>А где же они лежать будут? по логике все равно в python?.?/site-packages/
>>    
>>
>Нет. Питоньи скрипты (н-р, python-doc-tools) лежат не там.
>epydoc тоже лежит не там, вроде бы. Если нужно подумать над
>"версионно-независимом" каталоге для питона, его можно организовать,
>насколько я понимаю.
>
Ну так это же просто программы на питоне.
Однако все равно любая такая прога сложнее трех строк  зависит от  
импортируемых модулей из python?.?/site-packages/.
То бишь 99,9% пакетов все равно потребуют питона с набором дополнений 
под его версию. Плохо представляю себе, как должны выглядеть зависимости 
такого пакета. Причем все равно такие программы запросто не будут 
работать под тем или иным питоном даже при наличии нужных модулей.
Разве не проще разобраться с неработоспособностью пакета, увидев в 
репорте gdesklets22, а не gdesklets? Да и класть только 
некомпилированные модули в пакет, это фактически ухудшить качество 
пакета. Скомпилировать его юзер уже не сможет и ему будет выгоднее 
просто скопировать содержимое  к себе в хоум и запускать оттуда. На этот 
слакварный вариант целимся?

>>По моему, это излишнее усложнение. Поддерживается один питон, так и
>>пусть поддерживается.
>>Наоборот скорее от сорцов надо избавлятся (только без размножения 
>>пакетов).
>>    
>>
>Без разможения пакетов - плохо, по-моему. Я сейчас периодически сам
>заглядываю в твистедовые потроха, чтобы понять, что же имелось ввиду в
>доке.
>  
>
я имею в виду не молчаливое удаление *.py как это сделали с *.la, а 
некий инструмент, селектирующий систему после (и в процессе) установки.

А под размножением пакетов я имею в виду следующее:
что у нас сегодня есть из _одного_ пакета/дистрибутива Zope

Zope-DateTime - Date and time representation
Zope-DocumentTemplate - DocumentTemplate - DTML template engine
Zope-Modules - Zope modules used by ZServer and PCGI
Zope-RestrictedPython - RestrictedPython for protected environments
Zope-StructuredText - StructuredText - automatic text markup
Zope-TAL - TAL - XML template engine
Zope-Testing - Testing environment for Zope components
Zope-ZHome - ZHome - sample home directory of ZServer
Zope-ZODB - ZODB and BTrees - object-oriented database ZODB
Zope-ZPublisher - ZPublisher - Zope query proceeding
Zope-ZServer - ZServer - Zope Application Server
Zope-ZUtils - ZUtils - Zope startup and maintenance scripts
Zope-core - Libraries used by Zope and ZODB
Zope-ReST - ReST - ReStructuredText Document for Zope
Zope-reStructuredText - reStructuredText - enhanced automatic text markup

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

Представим себе еще расщепление на *.py *pyc и *.pyo и получим 30/45 
пакетов из одного дистра зопа.
Добавим туда немножко косяков с автозависимостями в rpm и вполне можно 
бежать за веревкой...

Замечу, что зоп, это здорово, но еще далеко не все.

Вот, что дополнительно используется только на www.linux-os.ru (ничего 
такого специфичного)

ArchExample    
CMFCalendar     
CMFQuickInstallerTool 
Epoz            
MailManager                 
TranslationService
ArchGenXML     
CMFCore           
CMFTopic              
Formulator      
PlacelessTranslationService 
UserTrack
Archetypes     
CMFDefault        
CMFUserTrackTool      
GroupUserFolder 
PloneSearchBox              
ZWiki
BTreeFolder2   
CMFFormController  
Localizer       
PloneWebMail               
CMFActionIcons 
CMFMessage                 
MPoll           
PortalTransforms            
generator
CMFBoard       
CMFPlone          
DCWorkflow            
MailBoxer       
PortalTransport             
validation

Перемножим и это на два/три пакета и получим совсем кашу.

>>>7. Программы, имеющие такую привязку (н-р, идущие вместе с конкретной
>>> версией питона) иcпользуют #!/usr/bin/env python<version> ...
>>> и могут таскать за собой байткод.
>>>      
>>>
>>В скриптах? и вы согласны переписывать все скрипты в модуле при переходе 
>>версий???
>>    
>>
>Если эти _скрипты_ завязаны на данную версию питона: да, согласен.
>Но, мой опыт (сборки twisted) показывает, что достаточно внятно разделить:
>вот этот пакет - модул{ь,и}, он[и] привязан[ы] к версии питона, а вот
>это - скрипты [из /usr/bin], которые одинаково хорошо работают как с
>твистедом, собранным под 2.2, так и с твистедом, собранным под 2.3
>  
>

а какой смысл в разделении? не проще ли собрать два пакета вместо 
четырех, полностью их скомпилировать и в дальнейшем сопровождать?

>>>8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать
>>> только байткод, а .py заворачивать в отдельные пакеты "для
>>> интересующихся" (по моему разумению, по схеме, напоминающей то, что
>>> делает Алекс Отт для емакса, хотя _это мои предположения_)
>>>      
>>>
>>И наплодить еще дубликатов-пакетов пачку.
>>    
>>
>У Андрея были практические соображения, почему в боевую версию НЕ надо
>пихать сорцы. С другой стороны, мой небольшой практический опыт
>показывает, что сорцы _иногда_ нужны.
>  
>
мой опыт говорит, что сырцы нужны всегда или почти всегда.
вот сейчас пытаюсь завести науменовскую crm 2.3 без сырцов и ни хрена не 
получается.
версия 2.2 с сырцами завелась практически сразу, потому как из них было 
видно, что конкретно не устраивает программу.

>>У меня вот зреет какое то общее средство под кодовым названием stripper.
>>    
>>
>...
>  
>
>>Также можно поставить правила по умолчанию и они будут срабатывать при 
>>установке пакетов сами.
>>    
>>
>Это никак не упихивается в рамки distutils?
>  
>
/usr/lib/python2.3/site-packages/libaltdist.py ?
не похоже.
Эта штука должна по идее сопровождать установленную систему все время 
его существования (как апт или control) и даже иметь страничку в 
конфигураторе (которого нет).
Вобщем пока все слишком непонятно, чтобы обсуждать рамки.

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

Re: [devel] Python Modules Policy:

[Alexey Morozov]

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

On Thu, Feb 12, 2004 at 11:29:59AM +0300, Алексей Любимов wrote:
> >Нет. Их можно будет собирать "неодновременно", т.е. в два прохода.
> >Может быть, даже автоматом.
> >
> А, так это в том смысле, что из одного спека за один проход собирать 
> пакеты для всех питонов трудоемко?
> Это как раз само собой разумеется.
> 
> Раз так, то на зоп в сизифе и все, что посложнее "hello world" можно (и 
> нужно) не забивать :)
См. письмо про RFC.
Андрей Орлов в джаббере высказал мнение, что, возможно, стоит пойти по
другому пути, с доводкой до ума libAltDist. Возможно, это тоже путь.
Более подробно он выскажется сам.

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


> >ldv@ уже предложил решение, которое, вроде бы, не хуже по последствиям,
> >но автоматизируется. Прокомментируйте его, пожалуйста.
> Менять макросы rpmbuild?
> По моему это источник еще одной головной боли.
> Опять будет куча unmets, как это происходит при любом чихе сейчас с 
> перлом и прочими.
См. моё решение. F*cking magic, но таки "работает для меня". Причем,
если нужно, добавки происходят относительно безболезненно, как _мне_
_кажется_ в _настоящее время_

> Но самое главное, будет непрозрачное повдение rpm при сборке пакета.
> Проблема с с зависимостями питона не так серьезна, чтобы рубить с плеча.
> По моему все очень просто - поставил Requires: python = %<pversion> и 
> получил нужную зависимость.
Все автоматом происходит. Аллилуйя! :-)

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

> >>>Предлагается подумать над следующими двумя полиси:
> >>>6. Программы на python, не зависящие от конкретной версии питона
> >>>(epydoc, python-doc-tools), собираются _без_ байткода и,
> >>>соответственно, без привязки к точной версии питона, используется
> >>>#!/usr/bin/env python ...
> >>>     
> >>>
> >>А где же они лежать будут? по логике все равно в 
> >>python?.?/site-packages/
> >>   
> >>
> >Нет. Питоньи скрипты (н-р, python-doc-tools) лежат не там.
> >epydoc тоже лежит не там, вроде бы. Если нужно подумать над
> >"версионно-независимом" каталоге для питона, его можно организовать,
> >насколько я понимаю.
> Ну так это же просто программы на питоне.
> Однако все равно любая такая прога сложнее трех строк  зависит от  
> импортируемых модулей из python?.?/site-packages/.
Да, конечно. Но они как правило говорят просто

import smth

а уж откуда этот smth потянется - забота того питона, при помощи
которого эта прога выполняется. Сменится питон, сменится и место.
Но это никак не заденет саму прогу (вопросы совместимости разных
версий _языка_ оставим в стороне)

> репорте gdesklets22, а не gdesklets? Да и класть только 
> некомпилированные модули в пакет, это фактически ухудшить качество 
> пакета. Скомпилировать его юзер уже не сможет и ему будет выгоднее 
> просто скопировать содержимое  к себе в хоум и запускать оттуда. На этот 
> слакварный вариант целимся?
Нет, Алексей, я, видимо, плохо объяснил свою точку зрения. Смотрите, как
это вижу себе я:

	* имеется Twisted (благо, он действительно имеется, собран и
	  подходит для примера)
	* при сборке образуются следующие модули:
		* python<NN>-Twisted - сборище _модулей_ из Twisted
		  (вероятно, я распилю этот пакет на Twisted,
		  Twisted-web, Twisted-gtk итп)
		* python-Twisted-utils - вещи, которые, грубо говоря,
		  идут в /usr/bin/ и от конкретной версии питон не
		  зависят
		* python-Twisted-doc и всё остальное прочее барахло,
		  которое потребно лишь девелоперам
		
> >Без разможения пакетов - плохо, по-моему. Я сейчас периодически сам
> >заглядываю в твистедовые потроха, чтобы понять, что же имелось ввиду в
> >доке.
> я имею в виду не молчаливое удаление *.py как это сделали с *.la, а 
> некий инструмент, селектирующий систему после (и в процессе) установки.
Ну, можно, конечно, оформить это как %def_without python_source,
но, гхм... В общем, думать надо.

> А под размножением пакетов я имею в виду следующее:
> что у нас сегодня есть из _одного_ пакета/дистрибутива Zope
> 
> Zope-DateTime - Date and time representation
...
> Zope-reStructuredText - reStructuredText - enhanced automatic text markup
> 
> То есть один дистрибутив расщепился на 15 пакетов, что уже много.
В общем, пилить его надо. Не знаю, какова ситуация именно с Zope, но
по зависимостям полный Twisted, если его паковать правильно, тянет,
н-р, pygtk, который тянет GTK+/Glade, а что начинается дальше, в общем,
рассказывать не надо, да? :-) И это несмотря на то, что я, в общем,
захотел безобидной вещи, простенький серверок поверх http запустить :-)
"Абидна, да-а?! Ничего нэ сдэлал, да-а?!"

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

Кстати, насчет .pyc vs .pyo. В .pyc есть какой-нибудь смысл при наличии
.pyo (кроме отдельно оговоренных единичных случаев)?

> Замечу, что зоп, это здорово, но еще далеко не все.
Угу. 
> 
> Вот, что дополнительно используется только на www.linux-os.ru (ничего 
> такого специфичного)
> 
> ArchExample
...
Супер.

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

twisted -ny server_start.py (или вообще .tap)

При этом версия питона "по умолчанию" мне, в общем, по барабану
(ну, при условии, что у меня код написан так, что его реально можно
таскать. Если таскать нельзя, то в том месте, которое таскать нельзя
стоит: "нужен именно pythonX.Y!" и старт обламывается). При этом мне не
нужно ни альтернатив (которые, вообще-то, не самостоятельные в данном
случае, а slave'ы на python), ничего специального. Выбор версии питона
происходит в момент пробегания по /usr/bin/python -> ... ->
/usr/bin/pythonX.Y


> >У Андрея были практические соображения, почему в боевую версию НЕ надо
> >пихать сорцы. С другой стороны, мой небольшой практический опыт
> >показывает, что сорцы _иногда_ нужны.
> мой опыт говорит, что сырцы нужны всегда или почти всегда.
> вот сейчас пытаюсь завести науменовскую crm 2.3 без сырцов и ни хрена не 
> получается.
> версия 2.2 с сырцами завелась практически сразу, потому как из них было 
> видно, что конкретно не устраивает программу.
Удачи :-))

> >Это никак не упихивается в рамки distutils?
> /usr/lib/python2.3/site-packages/libaltdist.py ?
> не похоже.
> Эта штука должна по идее сопровождать установленную систему все время 
> его существования (как апт или control) и даже иметь страничку в 
> конфигураторе (которого нет).
> Вобщем пока все слишком непонятно, чтобы обсуждать рамки.
Ну, когда-то надо начинать.


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

Re: [devel] Python Modules Policy:

[Алексей Любимов]

>См. письмо про RFC.
>Андрей Орлов в джаббере высказал мнение, что, возможно, стоит пойти по
>другому пути, с доводкой до ума libAltDist. Возможно, это тоже путь.
>Более подробно он выскажется сам.
>
>Сейчас, я так понимаю, нужно выслушать мнение тех, кто реально будет эти
>самые модуля собирать (и использовать).
>  
>
По моему, все трое уже высказались. :)

>>>ldv@ уже предложил решение, которое, вроде бы, не хуже по последствиям,
>>>но автоматизируется. Прокомментируйте его, пожалуйста.
>>>      
>>>
>>Менять макросы rpmbuild?
>>По моему это источник еще одной головной боли.
>>Опять будет куча unmets, как это происходит при любом чихе сейчас с 
>>перлом и прочими.
>>    
>>
>См. моё решение. F*cking magic, но таки "работает для меня". Причем,
>если нужно, добавки происходят относительно безболезненно, как _мне_
>_кажется_ в _настоящее время_
>  
>

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

>>Но самое главное, будет непрозрачное повдение rpm при сборке пакета.
>>Проблема с с зависимостями питона не так серьезна, чтобы рубить с плеча.
>>По моему все очень просто - поставил Requires: python = %<pversion> и 
>>получил нужную зависимость.
>>    
>>
>Все автоматом происходит. Аллилуйя! :-)
>  
>
не пугайте.

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

>Да, конечно. Но они как правило говорят просто
>
>import smth
>
>а уж откуда этот smth потянется - забота того питона, при помощи
>которого эта прога выполняется. Сменится питон, сменится и место.
>Но это никак не заденет саму прогу (вопросы совместимости разных
>версий _языка_ оставим в стороне)
>  
>

а зависимости в пакете на эти модули кто будет ставить и каким образом?
Если программа собрана под питон23, то и зависиость будет python23-smth. 
такой вариант работает.

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

>
>	* имеется Twisted (благо, он действительно имеется, собран и
>	  подходит для примера)
>	* при сборке образуются следующие модули:
>		* python<NN>-Twisted - сборище _модулей_ из Twisted
>		  (вероятно, я распилю этот пакет на Twisted,
>		  Twisted-web, Twisted-gtk итп)
>		* python-Twisted-utils - вещи, которые, грубо говоря,
>		  идут в /usr/bin/ и от конкретной версии питон не
>		  зависят
>		* python-Twisted-doc и всё остальное прочее барахло,
>		  которое потребно лишь девелоперам
>  
>


Вариант

pyhon22-Twisted  полный коплект в  варианте для pyhon22
pyhon22-doc

pyhon23-Twisted  полный коплект в  варианте для pyhon23
pyhon23-doc

+ Альтернатива slave к питону.


>>>Без разможения пакетов - плохо, по-моему. Я сейчас периодически сам
>>>заглядываю в твистедовые потроха, чтобы понять, что же имелось ввиду в
>>>доке.
>>>      
>>>
>>я имею в виду не молчаливое удаление *.py как это сделали с *.la, а 
>>некий инструмент, селектирующий систему после (и в процессе) установки.
>>    
>>
>Ну, можно, конечно, оформить это как %def_without python_source,
>но, гхм... В общем, думать надо.
>
ага.

>>То есть один дистрибутив расщепился на 15 пакетов, что уже много.
>>    
>>
>В общем, пилить его надо. Не знаю, какова ситуация именно с Zope, но
>по зависимостям полный Twisted, если его паковать правильно, тянет,
>н-р, pygtk, который тянет GTK+/Glade, а что начинается дальше, в общем,
>рассказывать не надо, да? :-) И это несмотря на то, что я, в общем,
>захотел безобидной вещи, простенький серверок поверх http запустить :-)
>"Абидна, да-а?! Ничего нэ сдэлал, да-а?!"
>

Зависимости, это как раз причина для распила. В zope я этой причины не 
пронаблюдал. Может, плохо смотрел.

>Кстати, насчет .pyc vs .pyo. В .pyc есть какой-нибудь смысл при наличии
>.pyo (кроме отдельно оговоренных единичных случаев)?
>  
>
Андрей явно более осведомлен.
По моему не нужны pyc

>>Вот, что дополнительно используется только на www.linux-os.ru (ничего 
>>такого специфичного)
>>
>>ArchExample
>>    
>>
>...
>Супер.
>
ерунда. он в плоне как раз и не установлен.

>>а какой смысл в разделении? не проще ли собрать два пакета вместо 
>>четырех, полностью их скомпилировать и в дальнейшем сопровождать?
>>    
>>
>Очень просто.
>Когда я ставлю/запускаю /это/ я говорю
>
>twisted -ny server_start.py (или вообще .tap)
>
>При этом версия питона "по умолчанию" мне, в общем, по барабану
>(ну, при условии, что у меня код написан так, что его реально можно
>таскать. Если таскать нельзя, то в том месте, которое таскать нельзя
>стоит: "нужен именно pythonX.Y!" и старт обламывается). При этом мне не
>нужно ни альтернатив (которые, вообще-то, не самостоятельные в данном
>случае, а slave'ы на python), ничего специального. Выбор версии питона
>происходит в момент пробегания по /usr/bin/python -> ... ->
>/usr/bin/pythonX.Y
>  
>
ну так и ставить нужную версию.
twisted23 или twisted22 если так уж не хочется альтернатив.

Re: [devel] Python Modules Policy:

[Alexey Morozov]

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

On Thu, Feb 12, 2004 at 06:22:14PM +0300, Алексей Любимов wrote:
> >См. письмо про RFC.
> >Андрей Орлов в джаббере высказал мнение, что, возможно, стоит пойти по
> >другому пути, с доводкой до ума libAltDist. Возможно, это тоже путь.
> >Более подробно он выскажется сам.
> >
> >Сейчас, я так понимаю, нужно выслушать мнение тех, кто реально будет эти
> >самые модуля собирать (и использовать).
> По моему, все трое уже высказались. :)
Где? Я видел реакцию на мой RFC исключительно от Андрея. И то, в общем,
неполную, а так "навскидку".

> >См. моё решение. F*cking magic, но таки "работает для меня". Причем,
> >если нужно, добавки происходят относительно безболезненно, как _мне_
> >_кажется_ в _настоящее время_
> все, что связано с rpm должно пройти проверку на совместимость с 
> сандменом. Иначе лично мне нет смысла разводить драку.
> Вроде проблем не должно быть...
Ну, я попробую утащить все это дело к Мише, и собрать в хэшере.
Благо, там немного...

> >>По моему все очень просто - поставил Requires: python = %<pversion> и 
> >>получил нужную зависимость.
> >Все автоматом происходит. Аллилуйя! :-)
> не пугайте.
Нет, Вы все-таки попробуйте :-)
pyserial.spec я выдал. У меня уже теперь есть спек на MySQL-python,
заточенный под. Дальше будут модули, от которых зависит Twisted и сам
Twisted.

> >Но для модулей такая зависимость реально нужна.
> Далеко не во всех питон-программах есть модули, но используются модули 
> почти везде.
И? Пускай себе используют, моя-то какая беда?

> Кроме того иногда нет нужды в строгих зависимостях. Спец софт или 
> девелоперский вариант вполне допускает такие фокусы.
Стоп, какие фокусы?

> >Да, конечно. Но они как правило говорят просто
> >import smth
> >а уж откуда этот smth потянется - забота того питона, при помощи
> >которого эта прога выполняется. Сменится питон, сменится и место.
> >Но это никак не заденет саму прогу (вопросы совместимости разных
> >версий _языка_ оставим в стороне)
> а зависимости в пакете на эти модули кто будет ставить и каким образом?
Очень просто
Requires: python-pyserial = <требуемая версия>
Оно автоматом предоставляется.
В смысле,
pythonXY-pyserial предоставляет pyserial
Если у программы нет предпочтений по поводу, какой питон ей
использовать, она просит именно "общую версию".

> Если программа собрана под питон23, то и зависиость будет python23-smth. 
> такой вариант работает.
Ну, "программа", в общем случае, ни под что не собрана, она сама по себе
программа. С #!/usr/bin/env python .. внутри. Как сделать так, чтобы
она хотела python-Module1 python-Module2 python-Module3, и при установку
в систему _еще_ одного питона, в _дополнение_ к существующему, автоматом
притаскивались pythonXY-Module1, pythonXY-Module2 итп, я [пока] не знаю.

> а если "универсальный вариант", то получится тот же коленчатый вал, 
> когда половина модулей в одном питоне, половина в другом, а программа 
> импортит оба множества и с любым питоном не работает при полном 
> непротиворечии в базе rpm.
Ну, надо что-то придумывать. Либо сказать, что те, кто держит у себя на
машине сразу _два_ питона, должны делать всё руками и внимательно.
Разница лишь в том, что предложенная мной схема _допускает_ возможность
решения в случае, если питонов больше одного. Но на уровне: "надо -
сделай сам". Хоть и предоставляет достаточно удобные [на мой взгляд ;-)]
ручки конечному пользователю.



> pyhon22-Twisted  полный коплект в  варианте для pyhon22
> pyhon22-doc
> 
> pyhon23-Twisted  полный коплект в  варианте для pyhon23
> pyhon23-doc
Ну, если под pyhonXY-doc имелся ввиду python-Twisted-doc (на самом деле,
документацию смысла плодить не имеет, она одинаковая), то примерно так и
будет. Ну, разве что, pythonXY-Twisted может называться как-нибудь типа
pythonXY-Twisted-full или около того.

> + Альтернатива slave к питону.
Альтернатива на _что_?

> 
> >Ну, можно, конечно, оформить это как %def_without python_source,
> >но, гхм... В общем, думать надо.
> ага.
Ну, тогда, когда нужны .py, тянем .src.rpm и пересобираем? Так что-ли?

> >В общем, пилить его надо. Не знаю, какова ситуация именно с Zope, но
> >по зависимостям полный Twisted, если его паковать правильно, тянет,
> >н-р, pygtk, который тянет GTK+/Glade, а что начинается дальше, в общем,
> >рассказывать не надо, да? :-) И это несмотря на то, что я, в общем,
> >захотел безобидной вещи, простенький серверок поверх http запустить :-)
> >"Абидна, да-а?! Ничего нэ сдэлал, да-а?!"
> Зависимости, это как раз причина для распила. В zope я этой причины не 
> пронаблюдал. Может, плохо смотрел.
М.б. Я не работал с Zope.

> >Кстати, насчет .pyc vs .pyo. В .pyc есть какой-нибудь смысл при наличии
> >.pyo (кроме отдельно оговоренных единичных случаев)?
> Андрей явно более осведомлен.
> По моему не нужны pyc
Ok.

> >Супер.
> ерунда. он в плоне как раз и не установлен.
Меня список впечатлил. Как говорится, и шо ви с этог'о имеете? :-)

> >При этом версия питона "по умолчанию" мне, в общем, по барабану
> >(ну, при условии, что у меня код написан так, что его реально можно
...
> >случае, а slave'ы на python), ничего специального. Выбор версии питона
> >происходит в момент пробегания по /usr/bin/python -> ... ->
> >/usr/bin/pythonX.Y
> ну так и ставить нужную версию.
> twisted23 или twisted22 если так уж не хочется альтернатив.
Ну, это да, конечно. Просто если держать обе сразу (у меня были такие
шальные мысли, по крайней мере, поначалу), то тогда их (программы)
приходится разводить по именам, городить альтернативы итп. А зачем,
если они все равно одинаковые? Поэтому я и поступил таким вот образом.

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

Re: [devel] Python Modules Policy:

[Алексей Любимов]

Alexey Morozov пишет:

>On Thu, Feb 12, 2004 at 06:22:14PM +0300, Алексей Любимов wrote:
>  
>
>>>См. письмо про RFC.
>>>Андрей Орлов в джаббере высказал мнение, что, возможно, стоит пойти по
>>>другому пути, с доводкой до ума libAltDist. Возможно, это тоже путь.
>>>Более подробно он выскажется сам.
>>>
>>>Сейчас, я так понимаю, нужно выслушать мнение тех, кто реально будет эти
>>>самые модуля собирать (и использовать).
>>>      
>>>
>>По моему, все трое уже высказались. :)
>>    
>>
>Где? Я видел реакцию на мой RFC исключительно от Андрея. И то, в общем,
>неполную, а так "навскидку".
>  
>
Молчание, это тоже мнение.
Лично уменя яду не набралось, чтобы возопить, а плюсов я пока тоже не 
пронаблюдал.
см далее.

>>>См. моё решение. F*cking magic, но таки "работает для меня". Причем,
>>>если нужно, добавки происходят относительно безболезненно, как _мне_
>>>_кажется_ в _настоящее время_
>>>      
>>>
>>все, что связано с rpm должно пройти проверку на совместимость с 
>>сандменом. Иначе лично мне нет смысла разводить драку.
>>Вроде проблем не должно быть...
>>    
>>
>Ну, я попробую утащить все это дело к Мише, и собрать в хэшере.
>Благо, там немного...
>  
>

вариант.

>>>>По моему все очень просто - поставил Requires: python = %<pversion> и 
>>>>получил нужную зависимость.
>>>>        
>>>>
>>>Все автоматом происходит. Аллилуйя! :-)
>>>      
>>>
>>не пугайте.
>>    
>>
>Нет, Вы все-таки попробуйте :-)
>pyserial.spec я выдал. У меня уже теперь есть спек на MySQL-python,
>заточенный под. Дальше будут модули, от которых зависит Twisted и сам
>Twisted.
>  
>
ближе к выходным попробую.

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

>>Кроме того иногда нет нужды в строгих зависимостях. Спец софт или 
>>девелоперский вариант вполне допускает такие фокусы.
>>    
>>
>Стоп, какие фокусы?
>  
>
да просто собрал пакет и отдал его редхатчику. у него же нет таких 
пакетов в конце концов.
или девелоперская версия с непонятными пока еще зависимостями...



>>>Да, конечно. Но они как правило говорят просто
>>>import smth
>>>а уж откуда этот smth потянется - забота того питона, при помощи
>>>которого эта прога выполняется. Сменится питон, сменится и место.
>>>Но это никак не заденет саму прогу (вопросы совместимости разных
>>>версий _языка_ оставим в стороне)
>>>      
>>>
>>а зависимости в пакете на эти модули кто будет ставить и каким образом?
>>    
>>
>Очень просто
>Requires: python-pyserial = <требуемая версия>
>Оно автоматом предоставляется.
>В смысле,
>pythonXY-pyserial предоставляет pyserial
>Если у программы нет предпочтений по поводу, какой питон ей
>использовать, она просит именно "общую версию".
>
>>Если программа собрана под питон23, то и зависиость будет python23-smth. 
>>такой вариант работает.
>>    
>>
>Ну, "программа", в общем случае, ни под что не собрана, она сама по себе
>программа. С #!/usr/bin/env python .. внутри. Как сделать так, чтобы
>она хотела python-Module1 python-Module2 python-Module3, и при установку
>в систему _еще_ одного питона, в _дополнение_ к существующему, автоматом
>притаскивались pythonXY-Module1, pythonXY-Module2 итп, я [пока] не знаю.
>  
>
так вот о том и речь.
с этой ерунды же все и началось, что при наличии нескольких питонов, (а 
это норма, учитывая необходимость пересборки всех модулей перед 
снесением старой версии)  зависимости получаются левыми...


>>а если "универсальный вариант", то получится тот же коленчатый вал, 
>>когда половина модулей в одном питоне, половина в другом, а программа 
>>импортит оба множества и с любым питоном не работает при полном 
>>непротиворечии в базе rpm.
>>    
>>
>Ну, надо что-то придумывать. Либо сказать, что те, кто держит у себя на
>машине сразу _два_ питона, должны делать всё руками и внимательно.
>Разница лишь в том, что предложенная мной схема _допускает_ возможность
>решения в случае, если питонов больше одного. Но на уровне: "надо -
>сделай сам". Хоть и предоставляет достаточно удобные [на мой взгляд ;-)]
>ручки конечному пользователю.
>  
>
да пока что "ручки" Орлова ничем не хуже. Что там, что там есть 
требование держать только один питон.
Чего тогда колготится?

>>+ Альтернатива slave к питону.
>>    
>>
>Альтернатива на _что_?
>  
>
на twisted. но это не обязательно, если поставить conficts друг на друга.

>  
>
>>>Ну, можно, конечно, оформить это как %def_without python_source,
>>>но, гхм... В общем, думать надо.
>>>      
>>>
>>ага.
>>    
>>
>Ну, тогда, когда нужны .py, тянем .src.rpm и пересобираем? Так что-ли?
>  
>
Я бы просто клал *.py в пакет *.doc в /usr/share/doc/src/путь от корня/*.py
Захотел исходничков - поставил *.doc и посмотрел.

Хотя в общем случае - не дело rpm такие слои нарезать. Дело рпм ставить 
пакеты и следить за минимумом зависимостей. И все...

>>>Супер.
>>>      
>>>
>>ерунда. он в плоне как раз и не установлен.
>>    
>>
>Меня список впечатлил. Как говорится, и шо ви с этог'о имеете? :-)
>  
>
половина, это зависимости plone + рассылка postboxer + форум cmfboard с 
зависимостями + клиент для imap почты + wiki.
И это все...



>  
>
>>>При этом версия питона "по умолчанию" мне, в общем, по барабану
>>>(ну, при условии, что у меня код написан так, что его реально можно
>>>      
>>>
>...
>  
>
>>>случае, а slave'ы на python), ничего специального. Выбор версии питона
>>>происходит в момент пробегания по /usr/bin/python -> ... ->
>>>/usr/bin/pythonX.Y
>>>      
>>>
>>ну так и ставить нужную версию.
>>twisted23 или twisted22 если так уж не хочется альтернатив.
>>    
>>
>Ну, это да, конечно. Просто если держать обе сразу (у меня были такие
>шальные мысли, по крайней мере, поначалу), то тогда их (программы)
>приходится разводить по именам, городить альтернативы итп. А зачем,
>если они все равно одинаковые? Поэтому я и поступил таким вот образом.
>
да конечно проще просто  поставить конфликт друг на друга. в 99% это 
будет самое умное решение.

Re: [devel] Python Modules Policy:

[Alexey Morozov]

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

On Thu, Feb 12, 2004 at 08:10:53PM +0300, Алексей Любимов wrote:
> >Нет, Вы все-таки попробуйте :-)
> ближе к выходным попробую.
Ok.

> >Ну, "программа", в общем случае, ни под что не собрана, она сама по себе
> >программа. С #!/usr/bin/env python .. внутри. Как сделать так, чтобы
> >она хотела python-Module1 python-Module2 python-Module3, и при установку
> >в систему _еще_ одного питона, в _дополнение_ к существующему, автоматом
> >притаскивались pythonXY-Module1, pythonXY-Module2 итп, я [пока] не знаю.
> так вот о том и речь.
> с этой ерунды же все и началось, что при наличии нескольких питонов, (а 
> это норма, учитывая необходимость пересборки всех модулей перед 
> снесением старой версии)  зависимости получаются левыми...
Нет. Модули должны иметь зависимость на pythonXY-RequiredModule.
Соответственно дерево модулей строится отдельно для каждого
питона. С программами - да, с ними хуже. С другой стороны, установка
двух питонов - это, все же, и правда для нуждающихся. А там и ручками не
грех подумать.

> >Ну, надо что-то придумывать. Либо сказать, что те, кто держит у себя на
> >машине сразу _два_ питона, должны делать всё руками и внимательно.
> >Разница лишь в том, что предложенная мной схема _допускает_ возможность
> >решения в случае, если питонов больше одного. Но на уровне: "надо -
> >сделай сам". Хоть и предоставляет достаточно удобные [на мой взгляд ;-)]
> >ручки конечному пользователю.
> да пока что "ручки" Орлова ничем не хуже. Что там, что там есть 
> требование держать только один питон.
> Чего тогда колготится?
Очень просто. Я этот вопрос уже задавал Андрею: в какой момент сносить
[старый] питон? В момент, когда он соберет новый? Я (точнее, Вы)
останетесь без Зопы (хе-хе, Поручик в восторге). Когда Андрей дособирает
Зопу? Это довольно длинный процесс, к тому же не факт, что то, что нужно
Вам он тоже переберет. Поэтому возникает два питона. На каком из них
ездить, в общем решает каждый конкретный пользователь сизифа. Мне вот
например, совершенно нет резону дожидаться, пока Андрей закончит свои
Зоповые разборки, я могу смело двинуть альтернативу на питонX.{Y+1} и
начать перебирать требуемые мне модуля. А кому-то без Зопы не жизнь,
и его все эти появляющиеся в репозитории модули под новый модный питон
совершенно не греют. Хуже того, если возникает где-то проблема, скажем,
с безопасностью, то человек _вынужден_ устраивать свой собственный
зоопарк модулей, потому что python-Module-%версия-%{релиз_с_фиксом} уже
собран для нового питона и для старого его придется перебирать
самостоятельно, а потом ВЕШАТЬ ПАКЕТ НА ХОЛД, чтобы не дай Бог, не
обновилось ненароком. Вот этих проблем я и пытаюсь избежать, придумывая
свой велосипед.

> >>+ Альтернатива slave к питону.
> >>   
> >>
> >Альтернатива на _что_?
> на twisted. но это не обязательно, если поставить conficts друг на друга.
Не надо conflicts. Собирать модули для новых версий станет ПРОСТО
НЕВОЗМОЖНО. Смотрите:

Twisted зависит от вагона и маленькой тележки других модулей. Чтобы
собрать пакет под новый питон надо (теоретически, по крайней мере),
поставить всё, от чего он зависит (хотя бы, для того, чтобы проверить
его фактическую работоспособность). Если мы ставим pyserial, собранный
для 2.3, и он при этом конфликтует с pyserial'ом, который под 2.2, то
pyserial под 2.2 сносится, заодно унося за собой весь твистед под 2.2.
Оба-на. Тут и правда становится очень жарко, все девелоперы, которые
так или иначе пользуются моей машиной, остаются без средств разработки,
и им ничего не остается, как начинать помогать мне собирать модули,
требуемые для твистеда под 2.3. Тыкскыть, не расслабляцца! Постановка
людей в экстремальные условия, как верно заметил Райдер в треде про
полиси, приводит к резкому увеличению производительности труда. Я, как
ПМ должен быть просто в восторге от такого :-). Но только вот, как бы
это... жестковато, добрее надо к людЯм относиться :-)

> Я бы просто клал *.py в пакет *.doc в /usr/share/doc/src/путь от 
> корня/*.py
> Захотел исходничков - поставил *.doc и посмотрел.
Вариант. 2All: Еще будут мнения?

> Хотя в общем случае - не дело rpm такие слои нарезать. Дело рпм ставить 
> пакеты и следить за минимумом зависимостей. И все...
Уж, что есть...

> >Меня список впечатлил. Как говорится, и шо ви с этог'о имеете? :-)
> половина, это зависимости plone + рассылка postboxer + форум cmfboard с 
> зависимостями + клиент для imap почты + wiki.
> И это все...
Понятно.

> >Ну, это да, конечно. Просто если держать обе сразу (у меня были такие
> >шальные мысли, по крайней мере, поначалу), то тогда их (программы)
> >приходится разводить по именам, городить альтернативы итп. А зачем,
> >если они все равно одинаковые? Поэтому я и поступил таким вот образом.
> да конечно проще просто  поставить конфликт друг на друга. в 99% это 
> будет самое умное решение.
См. выше про конфликт.


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

[devel] [JT] Re: Python Modules Policy:

[Michael Shigorin]

On Thu, Feb 12, 2004 at 08:10:53PM +0300, Алексей Любимов wrote:
> >>Кроме того иногда нет нужды в строгих зависимостях. Спец софт или 
> >>девелоперский вариант вполне допускает такие фокусы.
> >Стоп, какие фокусы?
> да просто собрал пакет и отдал его редхатчику. у него же нет
> таких пакетов в конце концов.

Нарисует заглушку, блин.  А то следом придет калдеровец и начнет
права качать =)

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

Re: [devel] Re: Python Modules Policy:

[Andrey Orlov]

On Wednesday 11 February 2004 16:46, Andrey Khavryuchenko wrote:
> Хм, а можно тем, кто эту дискуссию читает одним глазком напомнить эти
> соображения?

А просто незачем держать исходники на рабочем сервере. Мы сейчас без какой-либо 
необходимости держим весь  питоновский код в тройном экземпляре. Для некоторых продуктов
это серьезный объем. Кроме того, сам факт наличия на файловой системе исходников
вызывает соблан что-то там руками докрутить. Что, в общем, тоже неприятно.

Я на одном своем пакете опробовал такую схему:

module-X.X.X-altN.i586.rpm -- Содержит только *.pyo

module-src-X.X.X-altN.i586.rpm -- Содержит только *.py

Все зависимости строятся на module, module-src - ставится по необходимости руками. Собственно,
для разработчиков и для тех, кому реально надо что-то докрутить. Соотв. если стоят оба пакета,
то имеем примерно те же файлы, что и сейчас.

Это работает, хотя, конечно, количество пакетов резко возрастает, что не очень приятно, и есть
пара дополнительных граблей.

Я на этих выходных попробовал найти какие-л. альтернативы, например, что-то аналоичное
макросу install_langs, или использованию exclude-path, но пока что все найденные альтернативы
требуют более-менее серьезного вмешательства в код rpm. Патчик, конечно, можно написать,
но я еще не понимаю, будет ли это более удобно, чем вышеприведенная схема module / module-src,
которая лично меня удовлетворяет полностью.

ЗЫ: Стирание части файлов после установки мне не нравится по очевидном причинам: нарушение
синхронности между базой rpm и реальным состоянием файловой системы. Другое решение,
состоящие в том, чбы оставить только *.py также не прокатывает, так как прекомпиленный
байт-код серъезно улучшает эффективность решений на основе python.

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

Re: [devel] Python Modules Policy: (was: alternatives && postfix)

[Andrey Orlov]

On Tuesday 10 February 2004 13:15, Alexey Morozov wrote:
> 1. Он проставляет Obsoletes: pythonN в python{N+1} или делает
>    аналогичные изменения, о точном решении будет сообщено
>    дополнительно ориентировочно в конце недели.

В конце недели я занимался персборкой "кстати" вышедшего Z264, так
что с Obsoletes / Conflicts разобрался только-только. Я поставил Conflicts.
Причины и подробное описание будут в отдельном письме, тестовый пакет 
в дедалусе будет сегодня или завтра.

> 2. _Одновременная_ сборка пакетов под разные версии питона является
>    на данный момент ненужной ввиду своей трудоемкости.
> 3. Андрей думает над целесообразностью сборки пакетов вида
>    python<N>-ModuleName из исходника вида python-ModuleName

Пункты 2, 3 разрушают юзабельность решения с поддержкой и менеджментом
пакетов, основанной на использовании APT / RPM. Я крайне сожалею, но я против.
Подробности опять-таки в отдельном письме.

Вместо такого подхода более реальный и работающий - держать отдельный репозиторий
для исторического хлама, в который списывается пакет для py2.N в момент выхода пакета
для py2.N+1. 

> 4. Я выкладываю на woland свой текущий вариант спеков, попутно
>    думая над "полезными макросами"

Спек я посмотрел. Он мне понравился, хотя п.2,3 ставят его ценность под сомнение.
В тоже  время, если мы все-таки сохраним идею использования двух питонов (в чем
лично я очень сильно сомневаюсь), он может иметь ограниченное применения для
пересборки "почти обязательных" модулей (Например, коннекторов к базам данных). 

> 5. В полиси для питоньих модулей вносится обязательный
>    Requires: python = %<pversion>, где %<pversion> совпадает с
>    %__python_version того питона, для которого производилась сборка.

Т.е. то, что имеет место сейчас.

> Предлагается подумать над следующими двумя полиси:
> 6. Программы на python, не зависящие от конкретной версии питона
> 7. Программы, имеющие такую привязку (н-р, идущие вместе с конкретной

Я в принципе против обеих пунктов и уже устал объяснять почему: программ не зависящих
от конкретной версии питона не существует в природе. То, что у нас сейчас сделано
на альтернативах - значительно лучше. Обратите внимание на работу пакетов python23-tools-idle,
etc. Пока альтернатива цела - все OK. Что я думаю о тех, кто правит альтернативы руками
и копирует файлы из каталого в каталог минуя RPM, объяснять, очевидно, не надо. В любом
случае, с учетом текущего указания conflicts установка обоих питонов простым пользователем
становится невозможный, а "те, кому очень надо" как-нить разберутся.

> 8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать
>    только байткод, а .py заворачивать в отдельные пакеты "для

Размышления о байткоде ушли отдельным письмом.

Подытоживая выше сказанное, и чбы подвести итог под остальными письмами, я должен сказать:
я лишний раз убедился в том, что идея держать два "работоспособных" питона в дистрибутиве -
ошибочна в принципе, так как приводит к неразрешимому снижению юзабельности APT/RPM.
Иными словами, я остаюсь при своем мнении: питонN.M-1 должен использоваться только 
разработчиками devel@ и только в процессе перехода на pythonN.M. 

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

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

[devel] (was: Python Modules Policy)

[Andrey Orlov]

On Monday 16 February 2004 11:46, Andrey Orlov wrote:
> Пункты 2, 3 разрушают юзабельность решения с поддержкой и менеджментом
> пакетов, основанной на использовании APT / RPM. Я крайне сожалею, но я
> против. Подробности опять-таки в отдельном письме.

Краткое описание :

    Я поразмышлял над текущей ситуацией и вариантами ее улучшения и считаю,
    что любое из предложенных изменений ее ухудшает по объективными
    признакам.  Поэтому, единственное изменение которое предлагается
    оставить - это ввести ограничение на одновременную установку python22 /
    23.
    
Признаки, по которым сравниваются альтернативы :

    С точки зрения администрирования и использования ALTLinux, использование
    apt/rpm предоставляется следующие безусловно ценные возможности :
    
        1.  Состоятельность ограничений -- т.е. в любом валидном состояннии
            ограничений каждый пакет получает для своей работы необходимую
            среду;
            
        2.  "Выводимый" апгрейд -- Список пакетов, которые будут установлены
            после апгрейда системы может быть получен автоматически, т.е.
            без вмешательства оператора, на основе текущего состояния
            системы и репозитория;
            
    Сразу замечу, что отказ от любой из этих возможностей ставит под
    сомнение необходимость и возможность эксплуатации решений, основанных на
    apt/rpm.
    

Текущая ситуация ограничений на python и модули к нему:

    1.  Есть два альтернативных пакета python (python22 & python23);
    
    1'. Необязательное ограничение на одновременную установку  python22 &
    python23;

    2.  Все модули существуют в единственном варианте, собранные под один из
        пакетов python;
    
    3.  В модулях явно прописана зависимость на используемый пакет python;
    
    4.  Существуют целевые программы (например Zope), в единственном
        варианте, требующие один из пакетов python;
    
    
    Применим признаки сравнения :
    
        1.  При условии наличия ограничения 1', система ограничений
        состоятельна;
            
        2.  Апгрейд выводим (как пример - из рабочего сервера под master22,
            использующего Zope + python22 + MySQLdb + и т.п. я без малейших
            проблем командой apt-get upgrade получил сервер под сизиф, исползующий
            Zope + python23 + MySQLdb + и т.п., и собираюсь тоже самое проделать
            во вторник на другом сервере);
        
        
Введение многократно-собираемых пакетов :

    1.  Есть два альтернативных пакета python (python22 & python23)
    
    2.  Все модули существуют в двух вариантах, под каждый пакет python;
    
    3.  В модулях явно прописана зависимость на используемый пакет python;
    
    4.  Существуют целевые программы (например Zope), в единственном
        варианте или множественном вариантах, требующих один из пакетов
        python;

    Применим признаки сравнения :
    
        1.  Система ограничений состоятельна;
        
        2.  Апгрейд не выводим (как альтернатива примеру из предыдущего раздела -
            потребуется явная ручная установка всех парных пакетов, что для того сервера
            привело бы к отдаче 10ти команд apt-get install ..., оно конечно не трудно, 
            но нафига тогда apt вообще нужен?);

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

Сравнение результатов и размышления о :

   Текущее состоянии сохранияет оба признака, предлагаемое - однозначно
   разрушает второй признак и ставит под большое сомнение выполнение первого
   признака.
   
   Разрулить это можно усилив требование 4 до формулировки "Существуют
   целевые программы (например, Zope) в единственном варианте, содержащим
   зависимости на все модули, которые могут быть им использованы", что для
   такого пакета как Zope, вообще говоря, представляется крайне не
   эффективным, если вообще возможным.
   
   Нельзя не упомянуть возможный вариант решения, основанный на кляузе
   Obsoleted добавляемой в каждый из пакетов-модулей. Я поэксперементировал
   над этим, во-1-ых автоматического апгрейда не происходит, во-2-ых некая
   якобы ценная возможность (из-за которой, собственно, все и началось), под
   названием "возможность одновременного использования python22 / 3"
   теряется безвозвратно (т.е. rpm позволяет поставить оба пакета, но apt
   этого не понимает)..

   В заключении упомянем требование 1' : мне удалось сделать это ограничение
   "мягким", введя два пакета: pythonX.Y-strict & pythonX.Y-weak. Установка
   пакета *-weak позволяет держать установленным предыдующий питон, конечно,
   состоятельность при этом не гарантируется: т.е. решение для тех кто готов
   принять риск. Подробнее об этом см. в письме про python
    
Заключение :

    Я против введения схемы именования модулей для python, основанной на
    введении префикса версии интерпретатора, так как при этом apt / rpm,
    и, как следствие, сам Сизифус, становятся малоюзабельными. Возможное 
    решение желающим работать со старыми модулями python - создать отдельный 
    репозиторий, куда перекладывать старый пакет при выходе пакета, собранного 
    с новой версией. Насколько это реально нужно - зависит от наличия реальной
    необходимости работы с питоном старых версий в среде сизифус, лично я к
    такой необходимости отношусь очень скептически.
     
-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

Re: [devel] Python Modules Policy: (was: alternatives && postfix)

[Andrey Orlov]

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

On Monday 16 February 2004 11:46, Andrey Orlov wrote:
> что с Obsoletes / Conflicts разобрался только-только. Я поставил Conflicts.
> Причины и подробное описание будут в отдельном письме, тестовый пакет
> в дедалусе будет сегодня или завтра.

Введение :

    В существующем варианте системы зависимостей на пакетах python и модулей
    к ним, существует проблема, состоящая в несостоятельности системы
    ограничений, например:
    
        Zope требует python23
        
        Zope требует MySQLdb
        
        MySQLdb требует python22
        
    Приведет к установке Zope, python23, MySQLdb & python22, что окажется
    нераобтоспособным.  Возможное решение состоит в внесении дополнительного
    ограничения на совместную установку python23 & python22, что может быть
    не очень удобно для некоторых пользователей, готовых "рискнуть".
    
Предлагаемое решение :

    Спеки для мистического пакета test & test-module лежат в атаче, чбы
    пример заработал, в /etc/apt/pkgpriorities нужно добавить строчки
    test23, test23-strict, test22-weak (Кстати, к кому обращатся по поводу
    их внесения на постоянной основе для пакетов python?).
    
    Чбы проиллюстрировать работу, просто приведу несколько команд:
    
        1.  Установка старой версии :
        
            apt-get install test22
            
        2.1  Обновление ее до новой версии (старая версия будет снесена):
        
            apt-get install test23
    
        2.2  Установка новой версии с сохранением старой (для тех кому
        надо):
        
            apt-get install test23-weak
    
        2.2.1 Удаление старой версии
        
            apt-get install test23-strict
            
    Обычные пользователи проводят систему через стадии 1, 2.1; Разработчики,
    которым некоторое время могут быть реально нужны обе версии python,
    проводят систему через стадии 1, 2.2, 2.2.1, понимая при этом, что на
    стадии 2.2 система может оказаться не юзабельной.
    
Преимущества и недостатки решения :

    Раз уж оба пакета можно поставить, то умный apt должен бы находить
    решение (недопустимое) в системе ограничений, описанной в "введении",
    Правда, в моих опытах apt решение не находит, но я не знаю как к этому
    относится: не полному пониманию смысла ограничений мной, или ошибкой в
    apt. Если кто-то себя считает авторитетом в apt (LDV?) и ему это
    интересно - можно обсудить приватно. Если apt начнет находить решение,
    то стоит отказаться от пакетов *weak или вынести их в отдельный
    репозиторий, сделав ограничение строгим.
    
    В тоже время, по крайней мере "обычные" варианты апгрейда системы будут
    приводить к обязательному сносу старой версии python. Т.о. это работает.

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

    Есть упрощенный вариант, в котором нет пакета test23-strict, а его функции
    берет на себя пакет test23, этот вариант тоже работает. Правда, наличие
    в заголовке конфликта на самого себя выглядит неким хаком и внушает горячкее желание
    поближе ознакомится с обработкой зависимостей в apt/rpm. В принципе, если
    я проблем не найду, то именно второй вариант останетя для python.
    
-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

[-- Attachment #2: test22-module.spec --]
[-- Type: text/plain, Size: 386 bytes --]

%define curver	22
%define prever  21

Version: 2.3.3
Release: alt5.99
Name: test%curver-module
Summary: Stupid module
License: PSF
Group: Development/Python
Url: http://www.python.org/
Packager: Python Development Team <python@packages.altlinux.org>
Provides: test-module
Requires: test%curver-core

%description
test
package.

%prep
%build
%install
%__mkdir_p $RPM_BUILD_ROOT

%files 

[-- Attachment #3: test23-module.spec --]
[-- Type: text/plain, Size: 386 bytes --]

%define curver	23
%define prever  22

Version: 2.3.3
Release: alt5.99
Name: test%curver-module
Summary: Stupid module
License: PSF
Group: Development/Python
Url: http://www.python.org/
Packager: Python Development Team <python@packages.altlinux.org>
Provides: test-module
Requires: test%curver-core

%description
test
package.

%prep
%build
%install
%__mkdir_p $RPM_BUILD_ROOT

%files 

[-- Attachment #4: test23.spec --]
[-- Type: text/plain, Size: 1138 bytes --]

%define curver	23
%define prever  22

Version: 2.3.3
Release: alt5.991
Name: test%curver
Summary: An interpreted, interactive object-oriented programming language
License: PSF
Group: Development/Python
Url: http://www.python.org/
Packager: Python Development Team <python@packages.altlinux.org>
Provides: test
Requires: test%curver-core

%description
test
package.

%package weak
Summary: Python with weak conflicts: using with python22 are allowed
Group: Development/Python
Provides: test%curver-core
Conflicts: test%curver-strict
Requires: test%curver-base
%description weak

%package strict
Summary: Python with weak conflicts: using with python22 are allowed
Group: Development/Python
Provides: test%curver-core
Conflicts: test%curver-weak
Requires: test%curver-base
#Obsoletes: test%prever-core
Conflicts: test%prever-core
#Obsoletes: test%prever-strict
#Obsoletes: test%prever-weak
%description strict

%package base
Summary: Base python modules and executables
Group: Development/Python
Requires: test%curver-core

%description base

%prep
%build
%install
%__mkdir_p $RPM_BUILD_ROOT

%files 
%files weak
%files strict
%files base 

[-- Attachment #5: test22.spec --]
[-- Type: text/plain, Size: 1138 bytes --]

%define curver	22
%define prever  21

Version: 2.3.3
Release: alt5.991
Name: test%curver
Summary: An interpreted, interactive object-oriented programming language
License: PSF
Group: Development/Python
Url: http://www.python.org/
Packager: Python Development Team <python@packages.altlinux.org>
Provides: test
Requires: test%curver-core

%description
test
package.

%package weak
Summary: Python with weak conflicts: using with python22 are allowed
Group: Development/Python
Provides: test%curver-core
Conflicts: test%curver-strict
Requires: test%curver-base
%description weak

%package strict
Summary: Python with weak conflicts: using with python22 are allowed
Group: Development/Python
Provides: test%curver-core
Conflicts: test%curver-weak
Requires: test%curver-base
#Obsoletes: test%prever-core
Conflicts: test%prever-core
#Obsoletes: test%prever-strict
#Obsoletes: test%prever-weak
%description strict

%package base
Summary: Base python modules and executables
Group: Development/Python
Requires: test%curver-core

%description base

%prep
%build
%install
%__mkdir_p $RPM_BUILD_ROOT

%files 
%files weak
%files strict
%files base 

Re: [devel] Re: Python Modules Policy:

[Алексей Любимов]

>ЗЫ: Стирание части файлов после установки мне не нравится по очевидном причинам: нарушение
>синхронности между базой rpm и реальным состоянием файловой системы. 
>  
>
1) Я бы заменил слово "стирание части файлов" на обратимую архивацию или 
перемещение по заданным правилам (как вариант, в /dev/null), при этом не 
просто удалять часть файлов, а, возможно, менять дефолтные конфиги или 
создавать в /usr/share/doc/progname лог перемещений, то бишь активно

2) Может быть есть способы синхронизировать состояние базы rpm со 
изменеиями в списке? биндинг же для питона в rpm есть.

>Другое решение,
>состоящие в том, чбы оставить только *.py также не прокатывает, так как прекомпиленный
>байт-код серъезно улучшает эффективность решений на основе python.

Нет повода сомневаться.

Re: [devel] Re: Python Modules Policy:

[Alexey Morozov]

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

On Mon, Feb 16, 2004 at 11:07:39AM +0300, Andrey Orlov wrote:
> module-X.X.X-altN.i586.rpm -- Содержит только *.pyo
> module-src-X.X.X-altN.i586.rpm -- Содержит только *.py
> 
> Я на этих выходных попробовал найти какие-л. альтернативы, например,
> что-то аналоичное макросу install_langs, или использованию exclude-path,
> но пока что все найденные альтернативы требуют более-менее серьезного
> вмешательства в код rpm
Предлагается автоматизировать этот этап. Все равно для "правильных"
модулей инсталляция происходит как

%__python ... install ... --record=INSTALLED_FILES

Во-первых, я думаю, совершенно необходим макрос:

%python_install, который и проводит все необходимые шаги.
Далее его можно расширить так, чтобы из INSTALLED_FILES формировался
собственно INSTALLED_FILES (то есть, то, что пойдет в "основной" модуль)
и INSTALLED_SRC_FILES - исходники из /usr/lib/pythonX.Y/...

> . Патчик, конечно, можно написать,
И никаких патчиков. Все ложится в /etc/rpm/macros.d/


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

Re: [devel] (was: Python Modules Policy)

[Alexey Morozov]

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

On Mon, Feb 16, 2004 at 12:00:58PM +0300, Andrey Orlov wrote:
>     Я поразмышлял над текущей ситуацией и вариантами ее улучшения и считаю,
>     что любое из предложенных изменений ее ухудшает по объективными
>     признакам.  Поэтому, единственное изменение которое предлагается
>     оставить - это ввести ограничение на одновременную установку python22 /
>     23.
Без определения механизма апгрейдов питона это требование настолько
жёсткое, что мне кажется довольно трудно выполнимым. Причина: кроме
собственно питона пользователям Сизифа необходимы еще и прикладные
модули. Если в момент, когда в Сизиф отправляется очередная версия
питона, вместе с ним не отправляется /достаточное количество/ модулей,
собранных для данной версии, то, боюсь, радость пользователей будет
несколько омрачена.

Выход видится в создании двухтактного апгрейда: на первом мэйнтейнеры
пакетов просто пересобирают его для нового питона в каком-либо
"загончике", на втором в заранее объявленный момент вся масса пакетов
отправляется в incoming сизифа, замещая собой все существовавшие там до
этого модули (те, кто не прошел тест на Requires должны, видимо,
уничтожаться/переноситься в какой-нибудь "отстойник для инвалидов").

Ну, и я все же оставил бы возможность стандартизованной сборки модулей для
"obsolete" питона и возможность их относительно бесконфликтного
существования с "основной версией".

Придраться к проведенному анализу я, в целом, не могу, хотя например 
данный абзац вызвал у меня некоторое недоумение 
>     Я против введения схемы именования модулей для python, основанной на
>     введении префикса версии интерпретатора, так как при этом apt / rpm,
>     и, как следствие, сам Сизифус, становятся малоюзабельными.
Вообще говоря, истинность этого утверждения зависит целиком от
имплементации "стандартного окружения питон-модуля". Но, это, в общем,
достаточно мелкий момент, и, по сути, мне интересны два момента (в
порядке убывания приоритетов)

1. выработка адекватного для меня, как _пользователя_ Сизифа, механизма
   апгрейда питона
2. возможность минимальными усилиями, не ломающими работоспособности
   apt, оставлять на машине выбранную версию питона.


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

Re: [devel] (was: Python Modules Policy)

[Andrey Orlov]

В сообщении от Понедельник 16 Февраль 2004 14:03 Alexey Morozov написал:
> On Mon, Feb 16, 2004 at 12:00:58PM +0300, Andrey Orlov wrote:
> >     Я поразмышлял над текущей ситуацией и вариантами ее улучшения и
> > считаю, что любое из предложенных изменений ее ухудшает по объективными
> > признакам.  Поэтому, единственное изменение которое предлагается оставить
> > - это ввести ограничение на одновременную установку python22 / 23.

Уже по дороге на работу я понял, что решение есть. Оно такое:

1. Мы избавляемся от python23, ему на смену приходит python
2. Пакет python22 остается
3. В день выхода python24 мы делаем fork пакета python и пакет python23 
появляется вновь, уже как вспомогательный
4. Пакет python принимает версию python-2.4.0

В этом случае мы можем ввести префикс версии, введя соотв. python-<MODULENAME> 
для основного пакета и python23-<MODULENAME> etc для всех остальных.

И наш апгрейд всегда проходит гладко.

> 1. выработка адекватного для меня, как _пользователя_ Сизифа, механизма
>    апгрейда питона

Я не совсем понимаю, что такое механизм апгрейда адекватный для пользователя. 
Сизиф предполагает единственный метод апгрейда - apt-get upgrade. Если мы не 
ломаем возможность такого апгрейда бесчисленными форками - то это _работает_. 
Я уже писал о том, что у меня не вызвало ни малейших проблем провести апгрейд 
сервера.

> 2. возможность минимальными усилиями, не ломающими работоспособности
>    apt, оставлять на машине выбранную версию питона.

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

Такой вариант вас устраивает? Меня, кажется, да.

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

Re: [devel] Re: Python Modules Policy:

[Andrey Orlov]

В сообщении от Понедельник 16 Февраль 2004 13:20 Alexey Morozov написал:
> И никаких патчиков. Все ложится в /etc/rpm/macros.d/

Макрос чбы разрезать пакет на module & module-src это не проблема,
собственно я примерно так как вы написали и делаю, 
вот только %_install_langs это совсем другая функциональность.

Вы почитайте про %_install_langs, он совсем другое делает и без патчика
rpm эта функциональность не достигается, видимо. Я вчера полдня в исходниках
rpm ковырялся, думал, есть решение.

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

Re: [devel] (was: Python Modules Policy)

[Andrey Orlov]

В сообщении от Понедельник 16 Февраль 2004 14:03 Alexey Morozov написал:
> Выход видится в создании двухтактного апгрейда: на первом мэйнтейнеры
> пакетов просто пересобирают его для нового питона в каком-либо
> "загончике", на втором в заранее объявленный момент вся масса пакетов
> отправляется в incoming сизифа, замещая собой все существовавшие там до
> этого модули (те, кто не прошел тест на Requires должны, видимо,
> уничтожаться/переноситься в какой-нибудь "отстойник для инвалидов").

Вот в спорах об этом, я, как уже писал, не участвую. В теории я с этим 
согласен, на практике же должен напомнить, что загончик под название
дедалус (Death All Us или типа того) у нас уже есть. Я им, иногда, даже 
пользуюсь и сбсно при переходе на py23 предлагал воспользоватся им,
на что не получил от заинтересованных лиц ни одного отзыва, потому
оттестировал все что меня интересовало и бухнул в сизиф, посчитав
что остальным...., что остальных...., что осталные мне доверяют. 

Кстати, новый вариант питона и модулей к нему я предлагаю именно на дедалусе и 
оттестировать. Готовы?

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

Re: [devel] (was: Python Modules Policy)

[Alexey Morozov]

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

On Mon, Feb 16, 2004 at 04:02:07PM +0300, Andrey Orlov wrote:
> 1. Мы избавляемся от python23, ему на смену приходит python
> 2. Пакет python22 остается
> 3. В день выхода python24 мы делаем fork пакета python и пакет python23 
> появляется вновь, уже как вспомогательный
> 4. Пакет python принимает версию python-2.4.0
> 
> В этом случае мы можем ввести префикс версии, введя соотв. python-<MODULENAME>

> для основного пакета и python23-<MODULENAME> etc для всех остальных.
Я не против. Немного лишней работы, но, по крайней мере,
разруливаемо на уровне сборочных автоматов.

> И наш апгрейд всегда проходит гладко.
Да, видимо. Я не имею возражений по предлагаемой схеме.

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


> > 1. выработка адекватного для меня, как _пользователя_ Сизифа, механизма
> >    апгрейда питона
> Я не совсем понимаю, что такое механизм апгрейда адекватный для пользователя. 
> Сизиф предполагает единственный метод апгрейда - apt-get upgrade. Если мы не 
> ломаем возможность такого апгрейда бесчисленными форками - то это _работает_. 
> Я уже писал о том, что у меня не вызвало ни малейших проблем провести апгрейд 
> сервера.
Андрей, я повторяюсь, наверное, уже набил оскомину, но тем не менее:

_Когда_ Вы провели апгрейд сервера? Правильно, когда, _помимо_ питона,
собрали еще Zope, который, видимо, является одним из основных рабочих
средств для Вас. Причем, что характерно, переезд на Zope/python2.3 не
был безболезненным, и потребовал довольно много времени (здесь я
ориентируюсь исключительно на Ваши слова о степени работоспособности
новых сборок, поэтому заранее извините, если я чего-то недопонял)

А если человек пользуется, например, PyQt или еще какой-нибудь вещью,
которая не собрана/не собирается просто так под 2.3? Правильно, он
остается на 2.2. Никто не будет ставить "просто питон", нужен "питон/Zope",
"python/Twisted", "python/MySQL" итп.

При этом та схема, которую Вы предложили изначально (с жетским Conflicts
каждой следующей версии) вынуждает его холдить python на уровне 2.2. 
Причем, по мере увеличения количества питоновских модулей (и,
соответственно, увеличения времени пересборки всего под новый питон)
желания "апгрейдиться" будет становиться все меньше. Одним из следствий
этого является то, что число тестеров 2.3 сокращается, что, вообще говоря,
потенциально ухудшает сборку.

Далее в дело вступает фактор, когда мне реально требуется софтина XXX,
а она, в свою очередь, требует нового питона (при том, что проект мой -
на старом, например, потому что там [лучше] работает Zope или еще никто не
удосужился перебрать pygtk под 2.3). Что я делаю? Правильно, я ставлю
"Allow-Duplicated" и, таким образом, хороню идею автоматизированного
апгрейда. Спрашивается, за что боролись?


> Такой вариант вас устраивает? Меня, кажется, да.
Да, описанная Вами схема вполне приемлема для меня.

Касательно зависимостей на модули. Мне кажется, будет разумным, если
при "автоматической" сборке (т.е. python-<ModuleName>) межмодульные
зависимости оформляются как

Provides: python-<modulename>
Requires: python-<AnotherModule>

а при сборке "под устаревшую" версию:

Provides: pythonXY-<modulename>
Requires: pythonXY-<AnotherModule>

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

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


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

Re: [devel] (was: Python Modules Policy)

[Alexey Morozov]

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

On Mon, Feb 16, 2004 at 04:24:14PM +0300, Andrey Orlov wrote:
> Кстати, новый вариант питона и модулей к нему я предлагаю именно на дедалусе и 
> оттестировать. Готовы?
Да. И критерием для переезда в сизиф предлагаю считать работающую пересборку
всех существующих на данный момент в Сизифе модулей под новую схему.
Если какой-то пакет не пересобирается до указанного срока - это повод его
похоронить.


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

Re: [devel] Re: Python Modules Policy:

[Andrey Orlov]

On Monday 16 February 2004 13:07, Алексей Любимов wrote:
> 1) Я бы заменил слово "стирание части файлов" на обратимую архивацию или
> перемещение по заданным правилам (как вариант, в /dev/null), при этом не

Не вижу разницы

> 2) Может быть есть способы синхронизировать состояние базы rpm со
> изменеиями в списке? биндинг же для питона в rpm есть.

Есть, конечно. Но если уж на то пошло - то пропатчить rpm будет проще, там
почти есть необходимая функциональность - ключик exclude-path, добавить
к нему что-то типа exclude-regexp и готово. Это собственно один и варианов, 
о кторых я говорил. Есть и другие. stinfo/devel

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

Re: [devel] (was: Python Modules Policy)

[Andrey Orlov]

On Monday 16 February 2004 16:51, Alexey Morozov wrote:
> > Кстати, новый вариант питона и модулей к нему я предлагаю именно на
> > дедалусе и оттестировать. Готовы?
> Да. И критерием для переезда в сизиф предлагаю считать работающую
> пересборку всех существующих на данный момент в Сизифе модулей под новую
> схему. Если какой-то пакет не пересобирается до указанного срока - это
> повод его похоронить.

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

Поэтому будем действовать так:

1. Я свою текущую сборку питона пересобираю в виде python-* и отправляю в
дедал. Там много нововведений, так что одним больше - одним меньше ;)

2. Вы кидаете обновленный спек для собрки модулей с именами в формате
python-module-<ИМЯ МОДУЛЯ> (я удлинил имя, чбы не было конфликиктов с
бинарными модулями самого питонона. Вообще-то я уже высскказывался пару раз
против префексирования вообще, но на этот раз, похоже, придется согласится,
так что префикс - python-module) и перемещенными в группу
Development/Python/Modules (с LDV это надо согласовать, собственно, это
письмо - начало такого согласования);

3. Договариваемся с (LDV видимо) о включении ваших макросов "куда надо", и
размещении этого "где надо" в сизиф.

4. Мы с вами переписываем наши модули для работы с вашим или похожим спеком,
но главное - в формате python-module-<ИМЯ МОДУЛЯ> и с зависимостью на python
(возможно, на python-core, точно скажу по завершении п.1) и отправляем
модули в дедал.

5. Я апгрейжу свою тестовую тачку из дедала

6. Вам рекомендую сделать тоже самое.

7. Выжидаем 1неделю, и если не находим глюков - то переносим все в сизиф.

8. Кто проснулся только что - исправляет зависмости.

По срокам (указаны даты завершения):

1,2. 23 feb

3,4. 1 Mar

5,6. 3 Mar

7.  10 Mar

8.  15 Mar

Я думаю, месяца всем будет достаточно, т.образом 16 марта у нас новая схема
будет введена в строй.

Теперь что касается требований к "остальным" сборщикам питоновских модулей.
Дело новое, непроверенное, поэтому минимальное требование ("для тех кто не
хочет ставить опыты на себе") это зависимость python (см. замечание в п.4).

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

Отдельное замечание по поводу Zope и продуктов к нему: стандартизация
пакетирования Zope вопрос отдельный, и до разбирательства с переходом на
Z2.7 к пакетам Zope это имеет отношение только в плане зависимостей на
python, никаких переименований. Чгря, мое мнение - Zope это продукт одного
питона.



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

Re: [devel] Re: Python Modules Policy:

[Алексей Любимов]

Andrey Orlov пишет:

>On Monday 16 February 2004 13:07, Алексей Любимов wrote:
>  
>
>>1) Я бы заменил слово "стирание части файлов" на обратимую архивацию или
>>перемещение по заданным правилам (как вариант, в /dev/null), при этом не
>>    
>>
>
>Не вижу разницы
>
разница большая. в одном случае это элементарное безконтрольное 
выкидывание файлов из пакета, а в другом набор настраиваемых политик  с 
возможностью индивидуальных порправок без переустановок и дроблений 
пакетов.  Поставил в политику %nodoc &&  %nopy && %noman  и получил 
боевой вариант, а понадобилось получить из пакета документацию или 
sources и поставил на конкретный пакет %doc && %py  и сразу получил 
результат.

>
>  
>
>>2) Может быть есть способы синхронизировать состояние базы rpm со
>>изменеиями в списке? биндинг же для питона в rpm есть.
>>    
>>
>
>Есть, конечно. Но если уж на то пошло - то пропатчить rpm будет проще
>
может быть. но  имхо по таким поводам патчить rpm может оказаться 
неоправданным. надо же будет и поддерживать эти патчи...

>  
>

Re: [devel] (was: Python Modules Policy)

[Dmitry V. Levin]

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

On Tue, Feb 17, 2004 at 11:01:42AM +0300, Andrey Orlov wrote:
[...]
> 2. Вы кидаете обновленный спек для собрки модулей с именами в формате
> python-module-<ИМЯ МОДУЛЯ> (я удлинил имя, чбы не было конфликиктов с
> бинарными модулями самого питонона. Вообще-то я уже высскказывался пару раз
> против префексирования вообще, но на этот раз, похоже, придется согласится,
> так что префикс - python-module) и перемещенными в группу
> Development/Python/Modules (с LDV это надо согласовать, собственно, это
> письмо - начало такого согласования);

Если вам нужна дополнительная группа для модулей, то можно сделать, хоть я
и не улавливаю, зачем.

> 3. Договариваемся с (LDV видимо) о включении ваших макросов "куда надо", и
> размещении этого "где надо" в сизиф.

$ grep ^/etc/rpm/macros.d/ /path/to/Sisyphus/i586/base/contents_index
/etc/rpm/macros.d/alternatives	libalternatives-devel
/etc/rpm/macros.d/apache	apache-devel
/etc/rpm/macros.d/bmp	libbeep-devel
/etc/rpm/macros.d/control	control
/etc/rpm/macros.d/gconf2	GConf2
/etc/rpm/macros.d/gstreamer	gstreamer-devel
/etc/rpm/macros.d/kernel	kernel-build-tools
/etc/rpm/macros.d/ladspa_sdk	ladspa_sdk
/etc/rpm/macros.d/pam	/etc/rpm/macros.d/pam
/etc/rpm/macros.d/perl5	rpm-build-perl
/etc/rpm/macros.d/php	php-devel
/etc/rpm/macros.d/ruby	libruby-devel
/etc/rpm/macros.d/tcl	tcl-devel
/etc/rpm/macros.d/texinfo	texinfo
/etc/rpm/macros.d/vim	vim-devel
/etc/rpm/macros.d/xemacs	xemacsen
/etc/rpm/macros.d/xmms	libxmms-devel
/etc/rpm/macros.d/xscreensaver	xscreensaver-devel
/etc/rpm/macros.d/yelp	yelp

Так что решайте сообразно сложившейся традиции.


-- 
ldv

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

Re: [devel] (was: Python Modules Policy)

[Alexey I. Froloff]

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

On Sat, Feb 21, 2004 at 09:52:38PM +0300, Dmitry V. Levin wrote:
> > 3. Договариваемся с (LDV видимо) о включении ваших макросов "куда надо", и
> > размещении этого "где надо" в сизиф.
> $ grep ^/etc/rpm/macros.d/ /path/to/Sisyphus/i586/base/contents_index
[..skip..]
> Так что решайте сообразно сложившейся традиции.
А как же rpm-python?  Кажется именно из-за него в глобальном
rpmrc и появились %_*python.*

-- 
Regards,
Sir Raorn.

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