From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 27 Oct 2002 19:57:54 +0300 (MSK) From: Ivan Zakharyaschev X-X-Sender: ivan@arrakis.zephyrous To: ALT Devel discussion list Subject: Re: [devel] Q: site-lisp files In-Reply-To: <20021027122858.GE1092@basalt.office.altlinux.ru> Message-ID: X-Mailer: try to guess MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=koi8-r Content-Transfer-Encoding: 8BIT 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: 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 сделать не могут. По-моему, это очень неудобно: не о таких тонкостях построения системы из пакетов нужно думать пользователю. -- С наилучшими пожеланиями, Иван Захарьящев, Москва