[devel] Q: site-lisp files

[Ivan Zakharyaschev]

	Hello!

On Sun, 27 Oct 2002, Dmitry V. Levin wrote:

> On Sun, Oct 27, 2002 at 01:58:13PM +0300, Alex Ott wrote:
> > Да -- я думаю, что стоит это сделать для тех пакетов, которые идут
> с
> > одним/двумя файлами для Emacs.
>
> Информация к размышлению: .el-файлы.
>
> Всего в Сизифе на данный момент
> + 440 файлов вида ^/usr/share/emacs/site-lisp/.*\.el$
>   которые собраны из 34 исходных пакетов;
>   следующие 14 из этих пакетов не содержат в своем имени слова emacs:

> + 332 файла вида ^/usr/share/emacs/site-lisp/.*\.elс$

> Выводы:
> - Пакеты, содержащие файлы только одного из двух видов, очевидно,
>   делают это ошибочно.

Может быть, это не совсем чисто с точки зрения упаковки, но на
возможность использования это почти никак не влияет:

- и .elc, и .el могут быть загружены для использования во время работы
(.el чуть медленнее, есть бОльшая вероятность возникновения ошибки при
этом);

- .el как правило не нужны: с ними удобнее заниматься debugging, изучать
исходники и т.п. Когда их мало, самое удобное решение -- положить в
пакет вместе с .elc; когда много -- в отдельный пакет.

- И те и другие можно сжимать (gzip или bzip2). .elc я предпочитаю не
сжимать (мне кажется, это может замедлить загрузку), разве что большие и
редко используемые, а .el неплохо бы и сжать (в TODO к emacs-el).

> - Есть смысл все .el?-файлы вынести из основных пакетов.

Не знаю, есть ли смысл. По-моему, это создаст неудобства и для
пользователя и для packager-а: пользователь ожидает, что если у него
установлены Emacs и, скажем, gpm, то они смогут взаимодействовать друг с
другом. Если же gpm не установлен, то поддержка gpm в Emacs не нужна:
только место и время загрузки отнимает. (gpm, может, не самый удачный
пример, т.к. gpm -- не что-то редкое.)

Сейчас, по-моему, довольно естественная ситуация с тем, где лежат
el?-файлы, и их перемещение -- лишняя работа packager-ов (причём не
разовая, а постоянная), да ещё, на мой взгляд, не приносящая улучшений.

Какие есть варианты, куда класть el-бтблиотеку для взаимодействия:

1) в пакет с той программой, с которой она взаимодействует и вместе с
которой рапространяется el-исходник. Это примерно то, что сейчас есть, и
мне этот вариант больше всего и нравится. Лишних зависимостей от Emacs
это не создаёт (кроме тех, что при сборке), но даёт удобства
пользователю и packager-у: пользователь поставил emacs и эту программу и
работает;  вышла новая версия программы, packager пересобрал пакет, и ни
о чём больше думать не надо: el-библиотека, входящая в него, нормально
работает с новой версией, никакие другие пакеты в связи с этим изменять
не надо.

Остаётся, конечно, вопрос, почему у Emacs такое особое положение: другие
пакеты о нём заботятся, но не предоставляют модули для всевозможных
остальных редакторов.

2) пакет emacs общего назначения (emacs-common или планируемый
prog-misc и т.п.). Но тогда этот пакет может стать неоправданно
большим (включено много el-библиотек, обслуживающих всякие редкости),
трудно поддерживаемым (нужно доставать исходники из других мест и
следить за тем, что они совместимы с той версией программы, с которой
они взаимодействуют, которая установлена) и, возможно, имющим много
зависимостей (от всего того, с чем эти библиотеки взаимодействуют).
Обычно это неудобно пользователю и packager-у.

3) В отдельный пакет. Дял packager-а этот вариант по сравнению с 1)
почти ничего не меняет, но пользователю неудобно. Он поставил emacs,
поставил ещё какую-то штуковину, а они не взаимодействуют. От него
требуется лишнее ручное действие по установке el-библиотеки,
обеспечивающей это взаимодействие. Ничего лучшего rpm + apt
сделать не могут. По-моему, это очень неудобно: не о таких тонкостях
построения системы из пакетов нужно думать пользователю.

-- 
С наилучшими пожеланиями,
Иван Захарьящев, Москва