Здравствуйте. Имеет место вопрос по политике упаковки 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 разве что? Но тогда имеет смысл пройтись подобным образом по остальным питоньим пакетам. И имеем или существенное увеличение количества бинарных пакетов (минимум удвоение по питон-базированным), или нерациональное использование дискового пространства в большинстве случаев. -- ---- WBR, Michael Shigorin ------ http://visa.chem.univ.kiev.ua/~mike/