Hello Michael,

On Thu, Jan 31, 2002 at 05:11:24PM +0200, Michael Shigorin wrote:
>
> 	Здравствуйте.
> Имеет место вопрос по политике упаковки precompiled-скриптов и их
> исходников.  Так как проблема явно не ограничивается одним
> пакетом, просьба прокомментировать.
> 
> On Thu, Jan 31, 2002 at 02:38:58PM +0300, Stanislav Ievlev wrote:
> > >>>.py специально потеряли.  А вот насчет .pyo -- оптимизацию Юрий
> > >>>только сегодня туда и вкрутил ("нова возможность") ;-)
> > >>Не понял, чем они помешали ... какое-то скрытие исходников прямо.
> > >Да нет -- или i586 тоже является сокрытием исходников? ;)
> > >Юрий заметил, что .py необходимыми не являются, а вот место на
> > >диске занимают -- и поправил спек.  Я счел это резонным.
> > Это понятно, но все-равно не есть хорошо.
> > А если человек собрал свою версию питона и ему по-хорошему надо 
> > перекомпилировать байт код?
> rpm --rebuild (насколько я понимаю текущую политику, человек с
> "а если" подозревается в осознании своих действий и способности
> перебрать affected части системы).
> 
> > Что если что-то случиться с питоном (как уже неоднократно было) при 
> > очередном обновлении и он не сможет читать байт-код, выдавая "bad 
> > marshal data"?
> В сизифе или где?  Опять же, вопрос скорее policy.  Посему даю
> копию в devel и с надеждой жду ответа MhZ ;-)
> 
> На самом деле, по-моему, это не что иное, как резон для Requires
> на конкретную версию питона, с которой производилась
> прекомпиляция.
> 
> > Если есть *.py файлы, то человек сможет по крайней мере исправить 
> > ситуацию, а если нет?!!!
> А как он собирается исправлять ситуацию по принадлежащим некоему
> пакету файлам без прав рута? 
> 
> Кстати, а что сделает питон, если увидит лежащие рядом .py и
> более старый .py[oc], а прав на запись в каталог/файл не будет?)
> 
> И если будет иметь место перекомпиляция (рутом), то по крайней
> мере rpm -Va будет существенно замусорен, в отличие от
> rpm --rebuild *_на_питоне.
> 
> > Избыточная оптимизация скорее вредна, чем избыточна. Когда речь идет о 
> > скриптовых языках, то во избежание проблем скрипты должны быть.
> Опять же -- насколько я понимаю, налицо специфика.  Вот и давайте
> решим, что с ней делать.  По крайней мере в Вашем варианте,
> Станислав, имеем конфликт потенциально динамической природы
> скриптов (точнее, прекомпиляции) и статической сути той же базы
> rpm (не говоря о r/o натуре /usr).
> 
> > Если уж очень хотите прооптимизировать пакет, то гораздо правильнее 
> > разбить его на несколько подпакетов, например
> > solfedge-common
> > solfedge-precompiled
> > solfedge-py
> Вот примерно так и думали -- выделить .py ...куда?  В -devel --
> неправильно, для разработчика, скорее всего, все исходники, .po и
> Makefile потребуются.  В -py разве что?  Но тогда имеет смысл
> пройтись подобным образом по остальным питоньим пакетам.
> 
> И имеем или существенное увеличение количества бинарных пакетов
> (минимум удвоение по питон-базированным), или нерациональное
> использование дискового пространства в большинстве случаев.

В параграфе 6.1.2 tutorial'а по Python всё очень чётко написано.

Коротко:
- .pyo используются с опцией -O, .pyc в отсутствие этой опции;
- невозможность создать или обновить .pyc/.pyo при наличии .py
  не является ошибкой;
- отсутствие .py при наличии .pyc/.pyo не является ошибкой.

То есть .py можно и выделить в необязательный добавочный пакет,
как это сделано в emacs-el. Но все остальные python-related файлы
и то, что они используют, должны быть в основном пакете.
Нельзя ставить в зависимость работы скриптов опцию -O.
Нужно ещё учитывать, что .py понадобятся при отладке.
Вообще, если посмотреть по размерам, получается экономия примерно на
треть, не учитывая прочих файлов. Намного меньше, чем даёт
выделение статических библиотек в devel-static. Стоит ли
париться?

Оставить, скажем, только .pyo можно тогда, когда модули используются
строго с опцией -O и только для исполнения. В инсталляторе этот номер
пройдёт на ура.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
The Constitution may not be perfect, but it's a lot better than what we've got!