ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Michael Shigorin <mike@lic145.kiev.ua>
To: Stanislav Ievlev <inger@alt-linux.org>
Cc: devel@altlinux.ru
Subject: [devel] Q: что делать с *.py vs *.py[oc]? (was: solfege-1.4.1-alt0.9.src.rpm)
Date: Thu, 31 Jan 2002 17:11:24 +0200
Message-ID: <20020131151124.GQ4893@lic145.kiev.ua> (raw)
In-Reply-To: <3C592CD2.6080200@alt-linux.org>

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

	Здравствуйте.
Имеет место вопрос по политике упаковки 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 <mike@altlinux.ru>
  ------ http://visa.chem.univ.kiev.ua/~mike/

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

       reply	other threads:[~2002-01-31 15:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-31 15:11             ` Michael Shigorin [this message]
2002-02-01  9:51               ` [devel] " Mikhail Zabaluev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020131151124.GQ4893@lic145.kiev.ua \
    --to=mike@lic145.kiev.ua \
    --cc=devel@altlinux.ru \
    --cc=inger@alt-linux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git