From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 1 Feb 2002 12:51:48 +0300 From: Mikhail Zabaluev To: devel@altlinux.ru Message-ID: <20020201095148.GA25794@mhz.mikhail.zabaluev.name> Mail-Followup-To: Mikhail Zabaluev , devel@altlinux.ru References: <3C57C362.4070705@alt-linux.org> <20020130100917.GW1766@lic145.kiev.ua> <3C57C93E.3010609@alt-linux.org> <20020130122458.GA15771@lic145.kiev.ua> <3C580BA1.3000505@alt-linux.org> <20020130154729.GA1537@lic145.kiev.ua> <3C592CD2.6080200@alt-linux.org> <20020131151124.GQ4893@lic145.kiev.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <20020131151124.GQ4893@lic145.kiev.ua> User-Agent: Mutt/1.3.27i Subject: [devel] Re: Q: =?koi8-r?B?3tTPIMTFzMHU2CA=?= =?koi8-r?Q?=D3?= *.py vs *.py[oc]? (was: solfege-1.4.1-alt0.9.src.rpm) Sender: devel-admin@altlinux.ru Errors-To: devel-admin@altlinux.ru X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.0 Precedence: bulk Reply-To: devel@altlinux.ru List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Archived-At: List-Archive: List-Post: --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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! --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8WmU0TKqCuNPJlLgRAgRbAJ9nh0ZXPXME+3GxKXW0vO9bds+GggCfciEy yUfvXg8BIM4fdnLIeSUExsU= =MCK4 -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT--