From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 28 Oct 2002 02:10:46 +0300 From: "Dmitry V. Levin" To: ALT Devel discussion list Subject: Re: [devel] Q: site-lisp files Message-ID: <20021027231046.GA3502@basalt.office.altlinux.ru> Mail-Followup-To: ALT Devel discussion list References: <20021027122858.GE1092@basalt.office.altlinux.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: X-fingerprint: 9658 398D 181B 1200 8FC5 26B8 F6F8 846B C1E2 3429 Sender: devel-admin@altlinux.ru Errors-To: devel-admin@altlinux.ru X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: devel@altlinux.ru List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Sun, Oct 27, 2002 at 07:57:54PM +0300, Ivan Zakharyaschev wrote: > > Выводы: > > - Пакеты, содержащие файлы только одного из двух видов, очевидно, > > делают это ошибочно. > > Может быть, это не совсем чисто с точки зрения упаковки, но на > возможность использования это почти никак не влияет: > > - и .elc, и .el могут быть загружены для использования во время работы > (.el чуть медленнее, есть бОльшая вероятность возникновения ошибки при > этом); > > - .el как правило не нужны: с ними удобнее заниматься debugging, изучать > исходники и т.п. Когда их мало, самое удобное решение -- положить в > пакет вместе с .elc; когда много -- в отдельный пакет. > > - И те и другие можно сжимать (gzip или bzip2). .elc я предпочитаю не > сжимать (мне кажется, это может замедлить загрузку), разве что большие и > редко используемые, а .el неплохо бы и сжать (в TODO к emacs-el). Значит, .elc мы рекомендуем включать (по аналогии с .pyc/.pyo)? > > - Есть смысл все .el?-файлы вынести из основных пакетов. > > Не знаю, есть ли смысл. По-моему, это создаст неудобства и для > пользователя и для packager-а: пользователь ожидает, что если у него > установлены Emacs и, скажем, gpm, то они смогут взаимодействовать друг с > другом. Если же gpm не установлен, то поддержка gpm в Emacs не нужна: > только место и время загрузки отнимает. (gpm, может, не самый удачный > пример, т.к. gpm -- не что-то редкое.) > > Сейчас, по-моему, довольно естественная ситуация с тем, где лежат > el?-файлы, и их перемещение -- лишняя работа packager-ов (причём не > разовая, а постоянная), да ещё, на мой взгляд, не приносящая улучшений. > > Какие есть варианты, куда класть el-бтблиотеку для взаимодействия: > > 1) в пакет с той программой, с которой она взаимодействует и вместе с > которой рапространяется el-исходник. Это примерно то, что сейчас есть, и > мне этот вариант больше всего и нравится. Лишних зависимостей от Emacs > это не создаёт (кроме тех, что при сборке), но даёт удобства > пользователю и packager-у: пользователь поставил emacs и эту программу и > работает; вышла новая версия программы, packager пересобрал пакет, и ни > о чём больше думать не надо: el-библиотека, входящая в него, нормально > работает с новой версией, никакие другие пакеты в связи с этим изменять > не надо. Если бы еще и .elc-файлы создавались автоматически (как .pyc/.pyo), и не вытягивали вместе с emacs'ом жуткие сборочные зависимости... С ними, кстати, можно что-нибудь сделать? -- ldv --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9vHJ29viEa8HiNCkRAtJPAJ4vLT7FyrFnricC/Hsuo7jYwFAAnwCfce6+ z8DYPxkp/8mEGKQOA7N5IT4= =PY7c -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD--