[devel] Re: [sisyphus] pygame und Numeric

[devel] Re: [sisyphus] pygame und Numeric

[Andrey Orlov]

On Wednesday 23 June 2004 02:02, Andrey Orlov wrote:
> > вероятно, эти пакеты не входят во множество "моих" Орлова.
> Разумеется, я не мантейнер всех пакетов ;), но что мешает мантейнерам 
> разрулить их пакеты? Подробности того, как это сделать - в простейшем
> случае буквально за 5мин - описывались в рассылке  уже десяток раз. 

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

Но, простите, если например, пакет содержит файл хрен-знает-что.py, который
никем и никогда не исполльзуется - да и не может быть использован, так как зависет
от python2.3(win32api) - то это явная проблема пакета и его мантейнера, а не проблема
полиси. Есть и другие типовые проблемы, часть которых неодонокартно освещалась в рассылке 
devel - последний раз опять-таки сегодня.

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

Писать с такими проблемами лучше на python@neural.ru или в жабер. Поверьте, я разрулил
уже не один пакет и точно знаю, никаких неразрешимых проблем с полиси сейчас нет, 
хотя некотороые ошибки в AutoReqProv действительно есть - спасибо всем обращавщимся
за помощью, за то, что их проблемы помогли их найти.

PS: Конечно, ехидно ухмылятся из-за угла и винить во всем Орлова это проще чем прочитать FAQ
или попытатся поискать почему возникла проблема с вашим пакетом. Только такой подход, право,
неконструктивен.

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

Re: [devel] Re: [sisyphus] pygame und Numeric

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

Андрей, вы прекрасно понимаете уязвимость своей позиции.

У полиси по определению нет и не может быть проблем. Проблемы есть у 
майнтейнеров и пользователей сизифа. И претензий к Орлову тоже нет. Он 
ведь не взламывал серверы альтлинукс, чтобы по умолчанию изменить 
процедуру поиска зависимостей в пакетах, содержащих скрипты питона?

Претензии к тем, кто понимая, что нарушится сборка(установка) кучи 
пакетов, которые уже есть в сизифе, спокойно пропустил такое изменение.
То, что у нас  всего-то скрибус свалился, это показатель "питонизации" 
дистра.  И это при том, что интересных питоновых прог - потенциальных 
кандидатов в сизиф уже не одна тысяча...

Вносить изменния в спек может только майнтейнер и только если он 
понимает, что и зачем он делает. Питон в пакете зачустую идет 
опциональной добавкой и майнтейнер не имеет возможности его исправить - 
ему просто не на чем проверить/увидеть косяки. Тот же скрибус 100% такой 
случай. Зачем было ломать его установку? 

>Но, простите, если например, пакет содержит файл хрен-знает-что.py, который
>никем и никогда не исполльзуется - да и не может быть использован, так как зависет
>от python2.3(win32api) - то это явная проблема пакета и его мантейнера, а не проблема
>полиси. Есть и другие типовые проблемы, часть которых неодонокартно освещалась в рассылке 
>devel - последний раз опять-таки сегодня.
>
>  
>
Это ничего, что питоновые программы обычно пишуться не в стиле 
"(alt)linux only" и "A.Orlov 2004 compatible"?

1) Питоновый скрипт в пакете совсем не обязан быть рабочим. В конце 
концов, он может использоваться как пример. Как документация. Пусть даже 
в /usr/share/progname/*
2) Есть множество питоновых врапперов, которые цепляются ко всему в 
системе. freevo таким образом имеет добрую полусотню зависимостей на 
биндинги. Все это sugest зависимости, вызов которых обвязан в try ... 
except и не сказывается на работоспособности программы. Это норма.
3) Лишний файл сегодня может завтра без предупреждений быть 
задействован. Не надо без серьезной нужды удалять файлы "который никем и 
никогда не исполльзуется". Не смешивайте девелопмент программы и ее 
упаковку в пакеты. И без того нерабочих биндингов хватает...
4)Программа может действительно сложной. twisted, zope, freevo,gdesklets 
- сложные программы. Сломать их легко, исправлять трудно и далеко не 
всем под силу.

>PS: Конечно, ехидно ухмылятся из-за угла и винить во всем Орлова это проще чем прочитать FAQ
>или попытатся поискать почему возникла проблема с вашим пакетом. Только такой подход, право,
>неконструктивен.
>
>  
>
Для тех, кто в упор не видит конструктива (они знают, о ком речь) - ВОТ ОН:
-----------------------------------------------------------------------
вводная:
1) Не надо менять полиси под каждый чих. Правила должны быть простыми и 
понятными. Все, что надо, это признать, что не все пакеты прямо подходят 
под это полиси и такие пакеты должны идти без проверок по этим правилам. 
Естественно, несоответствие правилам - минус программе и довод в пользу 
невключения в дистр или даже сизиф.
2) Не забывайте про тех, кто дома собирает программы для себя. Они даже 
в рассылки не напишут, что у них не получилось собрать или поставить 
пакет. Но они имеют право на лояльность дистрибутива по отношению к 
сторонним пакетам.
3)Ну есть же миграция на новые сборки проблемы ее прозрачности.

предложение:

Поставить таки  по умолчанию:
FindReq: yes,nopython

Как только майнтейнер дозреет (или его доведут), он _самостоятельно_ 
поставит в _своем_ спеке FindProv: yes и отработает поиск зависимостей.

---------------------------------------Конструктив закончился.

ЗЫ
Еще раз. Упаковка программ обычно  преследует цели внедрить в 
дистрибутив РЕШЕНИЕ той или иной задачи или целого круга задач. То есть 
некое среднее между обеспечением работоспособности программы  с 
минимумом телодвижений при установке с одной стороны и  с максимумом 
гибкости в настройке посредством кручения стандартных дистрибутивных 
"ручек" с другой. У нас же упаковка, это на 99% поиск и лечение граблей, 
внесеных теми или иными скриптами в rpm с сопутствующим прибиванием 
самой программы. Результат на лице. Можете дальше пенять на зеркало, 
вернее на ехидство зрячих.

Re: [devel] Re: [sisyphus] pygame und Numeric

[Dmitry V. Levin]

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

On Thu, Jun 24, 2004 at 03:43:29AM +0400, Алексей Любимов wrote:
[...]
> предложение:
> 
> Поставить таки  по умолчанию:
> FindReq: yes,nopython

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


-- 
ldv

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

Re: [devel] Re: [sisyphus] pygame und Numeric

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

Dmitry V. Levin wrote:

>On Thu, Jun 24, 2004 at 03:43:29AM +0400, Алексей Любимов wrote:
>[...]
>  
>
>>предложение:
>>
>>Поставить таки  по умолчанию:
>>FindReq: yes,nopython
>>    
>>
>
>Нет, это не предложение.
>Даже не потому, что после фриза такие вещи делать нельзя, а просто потому,
>что внедрённую более месяца назад схему выключать общим рубильником не
>имеет смысла.
>
>  
>
В sisyphus RPMS.classic

find  -name "*.rpm"| xargs rpm -qip   | grep "^Packager.*cray@altlinux.ru"
25
for i in `find -name "*.rpm"`; do rpm -qp --requires $i | grep python > 
/dev/null && echo $i; done | wc -l
86

61 потенциально битый пакет во фризе - норма?

ЗЫ
Кстати, всего 86 пакетов, требующих питона, это диагноз почище всяких 
полиси.
Навскидку с  моей машины:
$ rpm -q --whatrequires python
gramps-1.0.0-avl1
python-imaging-1.1.4-alt5
python-Numeric-22.0-alt1
pygtk2-2.0.0-avl11
egenix-mx-base-2.0.5-alt3
rpm-python-4.0.4_2.3-alt37
pyorbit-2.0.0-alt4
alchemist-1.0.33-avl
yum-2.0.5-avl
PyXML-0.8.3-alt1
freevo-1.5-pre1.avl
twisted-1.2.0-avl
python-ctypes-0.6.3-alt
pyxmms-2.02-avl
pyxf86config-0.3.18-avl
libxml2-python-2.6.9-alt1
libglade2-2.3.6-alt1
libnewt-python-0.50.39_2.3-alt2
redhat-config-soundcard-1.0.8-avl
redhat-config-date-1.5.25-avl
redhat-config-mouse-1.1.2-avl

Re: [devel] Re: [sisyphus] pygame und Numeric

[Andrey Orlov]

On Thursday 24 June 2004 05:02, Алексей Любимов wrote:
> 61 потенциально битый пакет во фризе - норма?

Это ложь. Пятиминутное вмешательство мантейнера может исправить
ситуацию. Если у мантейнера пакета нет этих пяти минут - то пакет
все равно потенциально-битый независимо от полиси.

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

Re: [devel] Re: [sisyphus] pygame und Numeric

[Andrey Orlov]

On Thursday 24 June 2004 03:51, Dmitry V. Levin wrote:
> Нет, это не предложение.
> Даже не потому, что после фриза такие вещи делать нельзя, а просто потому,
> что внедрённую более месяца назад схему выключать общим рубильником не
> имеет смысла.

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

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

Re: [devel] Re: [sisyphus] pygame und Numeric

[Anton Farygin]

Алексей Любимов пишет:

<skip>

> 
> 1) Питоновый скрипт в пакете совсем не обязан быть рабочим. В конце 
> концов, он может использоваться как пример. Как документация. Пусть даже 
> в /usr/share/progname/*
> 2) Есть множество питоновых врапперов, которые цепляются ко всему в 
> системе. freevo таким образом имеет добрую полусотню зависимостей на 
> биндинги. Все это sugest зависимости, вызов которых обвязан в try ... 
> except и не сказывается на работоспособности программы. Это норма.
> 3) Лишний файл сегодня может завтра без предупреждений быть 
> задействован. Не надо без серьезной нужды удалять файлы "который никем и 
> никогда не исполльзуется". Не смешивайте девелопмент программы и ее 
> упаковку в пакеты. И без того нерабочих биндингов хватает...
> 4)Программа может действительно сложной. twisted, zope, freevo,gdesklets 
> - сложные программы. Сломать их легко, исправлять трудно и далеко не 
> всем под силу.

IMHO все можно сделать намного проще: надо ставить зависимости _только 
на то, что есть в Sisyphus_, а обо всем остальном выдавать Warning.


Rgds,
Rider

Re: [devel] Re: [sisyphus] pygame und Numeric

[alexey lubimov]

Anton Farygin wrote:

> IMHO все можно сделать намного проще: надо ставить зависимости _только 
> на то, что есть в Sisyphus_, а обо всем остальном выдавать Warning.
>
Еще круче. Результат сборки пакета начинает зависеть от текущего 
состояния зависимостей всего сизифа или вернее сборочного репозитария.

Re: [devel] Re: [sisyphus] pygame und Numeric

[Andrey Orlov]

On Thursday 24 June 2004 12:05, alexey lubimov wrote:
> Еще круче. Результат сборки пакета начинает зависеть от текущего 
> состояния зависимостей всего сизифа или вернее сборочного репозитария.

Ой Алексей, вам прям не угодишь ;)

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

Re: [devel] Re: [sisyphus] pygame und Numeric

[Anton Farygin]

Andrey Orlov пишет:
> On Thursday 24 June 2004 12:05, alexey lubimov wrote:
> 
>>Еще круче. Результат сборки пакета начинает зависеть от текущего 
>>состояния зависимостей всего сизифа или вернее сборочного репозитария.
> 
> 
> Ой Алексей, вам прям не угодишь ;)
> 

Нет, просто Алексей неправ.

Результат сборки пакета зависит от текущего состояния _Sisyphus_ а не 
сборочного репозитария.

Именно таким способом сейчас идет поиск зависимостей скриптов на bash.

Т.е. - в двух словах: запускаемая программа ищется в content_index и в 
пакет добавляется зависимость на тот пакет, в который входит запускаемая 
программа.

Единственное "но":

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

Т.е. что-то вроде

%skip_requires scribus

Но вообще это общее пожелание к rpm'у.

Rgds,
Rider

Re: [devel] Re: [sisyphus] pygame und Numeric

[Andrey Orlov]

On Thursday 24 June 2004 13:59, Anton Farygin wrote:
> Т.е. что-то вроде
> %skip_requires scribus
> 
> Но вообще это общее пожелание к rpm'у.

Антон, конкретно в python-policy это есть уже пол-года. Собственно со 
scribus проблему так и решили:

%add_python_skip_req scribus

Да и не только со scribus, существует определенный класс сходных пакетов (использование
embedded-python), с которыми решить что-то иначе невозможно.
Подробный анализ проблемы именно со scribus я кидал вчера в девел для обсуждения,
возникновение такой проблемы python-полиси не описывает в принципе - ибо
имеет дело не с python, а с расширенным интерпретаторо питона, ведущим
себя. вообще говоря, не так, как обычный питон и не полностью совместимый с нии как минимум
по библиотекам. 

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

Re: [devel] Re: [sisyphus] pygame und Numeric

[Andrey Orlov]

On Thursday 24 June 2004 09:46, Anton Farygin wrote:
> IMHO все можно сделать намного проще: надо ставить зависимости _только 
> на то, что есть в Sisyphus_, а обо всем остальном выдавать Warning.

Антон, если вы предложите способ как это сделать...... то оно тут же будет сделано.
По-моему это невозможно.


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

Re: [devel] Re: [sisyphus] pygame und Numeric

[Anton Farygin]

Andrey Orlov пишет:
> On Thursday 24 June 2004 09:46, Anton Farygin wrote:
> 
>>IMHO все можно сделать намного проще: надо ставить зависимости _только 
>>на то, что есть в Sisyphus_, а обо всем остальном выдавать Warning.
> 
> 
> Антон, если вы предложите способ как это сделать...... то оно тут же будет сделано.
> По-моему это невозможно.

Это реально. Именно так сейчас работает поиск зависимостей у bash.

Достаточно сделать что-то вроде python_content_index, где перечислить 
все, что провайдит python'овские модули. На эту тему можно посмотреть 
текущий content_index.

И соответственно при поиске зависимостей использовать именно его.

Rgds,
Rider

Re: [devel] Re: [sisyphus] pygame und Numeric

[Andrey Orlov]

On Thursday 24 June 2004 13:56, Anton Farygin wrote:
> Это реально. Именно так сейчас работает поиск зависимостей у bash.
> все, что провайдит python'овские модули. На эту тему можно посмотреть 
> текущий content_index.

Ладно, про возможность установки пакетов не-из-сизифа я промолчу,
пока по крмре, но вот еще два вопроса:

1. А как, собственно, сделать "Слабую Зависимость"? По-моему rpm
такой возможности не предоставляет - есть Requires: .... и все?

2. Как, все-таки, будет работать модуль, в котором находится оператор
import <ЧТО-ТО-ТАМ>, а никакого <ЧТО-ТО-ТАМ> в системе нет?

Проблема-то не в том, что находятся зависимости, которых нет, зависимости
реально есть, и без них модули реально не работают...

> И соответственно при поиске зависимостей использовать именно его.

Точнее, при очистке списка зависимостей от потенциально-неудовлетворямых.

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

Re: [devel] Re: [sisyphus] pygame und Numeric

[Anton Farygin]

Andrey Orlov пишет:
> On Thursday 24 June 2004 13:56, Anton Farygin wrote:
> 
>>Это реально. Именно так сейчас работает поиск зависимостей у bash.
>>все, что провайдит python'овские модули. На эту тему можно посмотреть 
>>текущий content_index.
> 
> 
> Ладно, про возможность установки пакетов не-из-сизифа я промолчу,
> пока по крмре, но вот еще два вопроса:
> 
> 1. А как, собственно, сделать "Слабую Зависимость"? По-моему rpm
> такой возможности не предоставляет - есть Requires: .... и все?

Именно.

> 
> 2. Как, все-таки, будет работать модуль, в котором находится оператор
> import <ЧТО-ТО-ТАМ>, а никакого <ЧТО-ТО-ТАМ> в системе нет?

Такого быть не должно.

> 
> Проблема-то не в том, что находятся зависимости, которых нет, зависимости
> реально есть, и без них модули реально не работают...

Насколько я понял - проблема в том, что находятся зависимости, которых нет

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

Да, или гарантированно - не нужных, типа:
[ -x /bin/sh ] && /bin/sh

Rgds,
RIder

Re: [devel] Re: [sisyphus] pygame und Numeric

[Andrey Orlov]

On Thursday 24 June 2004 15:21, Anton Farygin wrote:
> > Проблема-то не в том, что находятся зависимости, которых нет, зависимости
> > реально есть, и без них модули реально не работают...
> 
> Насколько я понял - проблема в том, что находятся зависимости, которых нет

Нет, такого не отмечено. Даже в режиме strict, когда искалка зависимостей
находит даже ссылки на святую троицу, это не наблюдается, а уж в режиме slight - 
и подавно. Бывает только такое, что не находятся провайдес под существующие
зависимости. Причины у этого разные - есть, скажем, две ошибки в find-prov-py, или
особый случай с ранее упомянутым scribus - их мы лечим, а вот нахождение несуществующих
зависимостей - такого нет.

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

Собственно ни один из самплов scribus с чистым питоном не запускается.

> > Точнее, при очистке списка зависимостей от потенциально-неудовлетворямых.
> Да, или гарантированно - не нужных, типа:
> [ -x /bin/sh ] && /bin/sh

Для гарантирровано-ненужных есть %add_python_skip_req.
На самом деле, наличие описанного вами списка меня в основном обнадеживает
благодаря тому, что для пакетов, аналогичных scribus, Zope, etc можно очень сильно
улучшить поиск зависимостей. Дело в том, что сейчас если зависимость на python2.3(МОДУЛЬ)
поставляет Zope (например, его продукт), то это совсем не означает, что его увидит
кто-то кроме Zope. Даже скорее всего _не_ увидит. Я могу скоректировать
искальку porvides так, что такие Zope-специфичные provides будут называтся, скажем,
zope(модуль), но дело в том, что для искалки зависимостей я этого сделать не могу.
И это проблема - так как несморя на явный прорыв с зависимостями, мы все равно имеем
потенциальный источник неработоспособных пакетов.

А если есть индекс пакетов, которые провайдятся в дистрибутиве в _принципе_, то да,
если для Модуль есть провайдес на zope(Модуль) - зависимость переименовывается в zope(модуль)
и все проблема разруливается.

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

Re: [devel] Re: [sisyphus] pygame und Numeric

[Andrey Orlov]

On Thursday 24 June 2004 03:43, Алексей Любимов wrote:
> Андрей, вы прекрасно понимаете уязвимость своей позиции.

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

> Претензии к тем, кто понимая, что нарушится сборка(установка) кучи 
> пакетов, которые уже есть в сизифе, спокойно пропустил такое изменение.

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

> ему просто не на чем проверить/увидеть косяки. Тот же скрибус 100% такой 
> случай. Зачем было ломать его установку? 

Ее никто не ломал. Увидил unmets - посмотрел - спросил - исправил. Обычная 
работа. Я такое вижу в сизифе уже три года (до того не пользовался), сам тоже
наступал на грабли, даже ругался пару раз. Ну и что?

> 1) Питоновый скрипт в пакете совсем не обязан быть рабочим. В конце 
> концов, он может использоваться как пример. Как документация. Пусть даже 
> в /usr/share/progname/*

В FAQ описан способ позволяющий решить такие задачи в течении 5минут.
Прочитайте наконец документацию. У мантейнера scribus ушло повидимому
не больше времени после прочтения доки.

Кстати, насколько я помню, если положить скрипт с документацией в каталог /usr/share/doc
(где собственно и должна лежать документация), зависимости в нем искаться не будут. Можете
проверить - если это не так, повесте на rpm-build-python багу.

> 2) Есть множество питоновых врапперов, которые цепляются ко всему в 
> системе. freevo таким образом имеет добрую полусотню зависимостей на 
> биндинги. Все это sugest зависимости, вызов которых обвязан в try ... 
> except и не сказывается на работоспособности программы. Это норма.

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

> 3) Лишний файл сегодня может завтра без предупреждений быть 
> задействован. Не надо без серьезной нужды удалять файлы "который никем и 
> никогда не исполльзуется".

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

> 1) Не надо менять полиси под каждый чих. Правила должны быть простыми и 
> понятными. Все, что надо, это признать, что не все пакеты прямо подходят 

Не меняется уже полгода. И не собирается изменятся. 

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

Прочитайте FAQ. Все проверки можно отключить двумя опциями

> 3)Ну есть же миграция на новые сборки проблемы ее прозрачности.

Прочитайте FAQ. Все проверки можно отключить двумя опциями. И миграция
будет прозрачной.

> Поставить таки  по умолчанию:
> FindReq: yes,nopython

Отклоняется, так как работать все равно не будет - поставленные пакеты 
не найдут зависимостей. Прочитайте документацию наконец, а?

> Как только майнтейнер дозреет (или его доведут), он _самостоятельно_ 
> поставит в _своем_ спеке FindProv: yes и отработает поиск зависимостей.

Полгода дозревали - времени было более чем достаточно.
> ---------------------------------------Конструктив закончился.

Если "давайте ничего не будем меня потому что я не дозрел до прочтения двух
страниц документации" - это конструктив, то мне вам просто нечего сказать. 

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

[devel] meta-policy on policies and changes (was: pygame und Numeric)

[Michael Shigorin]

On Thu, Jun 24, 2004 at 03:43:29AM +0400, Алексей Любимов wrote:
> Вносить изменния в спек может только майнтейнер и только если
> он понимает, что и зачем он делает. Питон в пакете зачустую
> идет опциональной добавкой и майнтейнер не имеет возможности
> его исправить - ему просто не на чем проверить/увидеть косяки.
> Тот же скрибус 100% такой случай. Зачем было ломать его
> установку? 

Лёш, как ты знаешь, я чуть ли не первый открываю пасть при
эксцессах, подобных описываемым тобой (и не только).

_Но_ если бы предыдущие прецеденты обрабатывались настолько же
последовательно, как это сделал Андрей -- проблем было бы куда
меньше и тогда.

Под "настолько же" подразумевается:

- публичный анонс и драфт полиси;
- обкатка в Daedalus с привлечением _всех_ заинтересованных;
- доработка полиси;
- переезд в Sisyphus;
- внятное описание типичных проблем/решений предложение помощи
  майнтерам (в т.ч. вроде меня, которым от python не холодно и не
  жарко, как и от e.g. bash).

Я понимаю, что ты -- более заинтересованное лицо, но ёлы-палы --
где ты был, когда полиси делали/тестили/рихтовали? (ровно то, что
было намотано "на свой ус" в "других случаях" -- на будущее)

Посему предлагаю в будущем скорее смотреть, как делаются
дистрибутивообразующие изменения, на этом примере, нежели бегать
с ведром дегтя.

Угу?

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