[devel] Re: [mdk-re] /etc/emacs/site-start.d

Ivan Zakharyaschev =?iso-8859-1?q?vanyaz_=CE=C1_mccme=2Eru?=
Сб Май 5 14:07:38 MSD 2001


On Sat, 5 May 2001, Sergey Vlasov wrote:

> On Sat, 5 May 2001 00:39:29 +0400 (MSD)
> Ivan Zakharyaschev <vanyaz на mccme.ru> wrote:
>
> > Я отчасти поддерживаю идею об использовании /etc/emacs/site-start.d
> --
> > по
> > аналогии с, например, /etc/profile.d; сравнение с старт-стоп
> скриптами
> > не
> > очень подхолит, так как они настраивают сервер, а profile задает
> > конфигурацию для отдельного пользователя.
> >
> > Удобство такой директории понятно: не нужно лезть в один файл, чтобы
> > что-то добавить, достаточно просто положить в директорию.
> >
> > Но есть, по-моему, и большие неудобства. Они связаны как раз с
> разницей
> > между initscripts и profile: раз это конфигурация для пользователя,
> то
> > неплохо бы каждому отдельному пользователю иметь контроль над тем,
> что у
> > него будет грузиться, а что нет. А тут получается, как администратор
> > скажет, так всем и жить.

> > Можно попробовать решить эту проблему, создав структуру директорий,
> > похожую на ту, что есть в initscripts: есть /etc/emacs/site-start.d/,
> > где
> > лежат скрипты, но не выполняются, и у каждого есть
> > ~/.emacs/site-start.d/,
> > куда кладутся ссылки на реальные скрипты из /etc/emacs/site-start.d/
> > (можно будет их включать/выключать у разных пользователей, как и
> сервисы
> > в разных runlevels). Не слишком ли это громоздко?
>
> Не получится, ~/.emacs уже занят. :-)
>
> Ладно, имя придумать можно, но опять же после установки пакета в этот
> каталог автоматически ничего не попадет, и опять у начинающих
> пользователей возникнут вопросы - "а вот я тут поставил XXX, а его не
> видно". А вариант с помещением команд загрузки в /etc/skel*/.emacs,
> чтобы
> они попадали в ~/.emacs каждому новому пользователю, не лучше? Кому не
> нравится автозагрузка - может удалить их и загружать частями только то,
> что ему нужно.

skel-то этим и неудобен: он одноразового использования и изменения
отразяться только на вновь создаваемых пользователях.

Чтобы у всех сразу заработало то, что ставится новое, можно сделать так,
чтобы изначально у только что созданного пользователя этот
~/.emacs-user-start.d был просто ссылкой на /etc/emacs/site-start.d/ (или
какое-нибудь другое место, в котором лежат все возможные скрипты
автозагрузки для Emacs -- название site-start.d тут не очень подходит). И
тогда такой пользователь будет получать все новое, совершая минимум усилий
головой и пальцами: у него будет грузиться все.

Если же он задумается об этом и захочет сам определить набор того, что
будет авто-загружаться у него, то он сможет убрать ссылку
/.emacs-user-start.d, и завести на ее месте свою директорию, внутри
которой будут свои скрипты и ссылки на отдельные скрипты из общей
/etc/emacs/site-start.d/. Перед таким пользователем проблемы в том, что
что-то у него не запускается, хотя это и установлено, стоять не должно: он
сам на себя взял ответственность за слежение за этим. Для облегчения его
работы можно сделать специальный скрипт наподобие chkconfig.

Может, это и слишком громоздко, но большинство пользователей будет
избавлено от соприкосновения с этим ссылкой на общую
/etc/emacs/site-start.d/. Ее-то и надо положить в /etc/skel*.

Кажется, что никаких преимуществ такой конструкции по сравнению с
использованием просто ~/.emacs нет. Но они все-таки есть: все существующие
пользователи при раскладе по умолчанию будут получать автозагружаемыми
новые, установленные после появления этих пользователей компоненты Emacs.


Думаю, такую схему можно применить и ко многим другим элементам из skel:
изначально всякие конфигурационные файлы/директории просто указывают на
файлы из некоторого общего /etc/user-defaults/LOCALE/. И все обновления,
которые там делаются, легко доносятся до всех пользователей; от них это не
требует никаких усилий. Это до той поры, пока пользователь не захочет
что-то поменять в каком-то кофигурационном файле. В таком случае он
заменяет ссылку у себя в ~ на копию этого файла и вносит в нее изменения.
Отныне он сам следит за ним, а не полагается на умолчания.

А еще правильнее было бы, если все приложения поддерживали разную
конфигурацию по умолчанию для разных locale. Например, если бы можно было
в /etc/cups/lpoptions записать много вариантов значений одних и тех же
параметров для разных locale.

-- 
Best regards,
	Ivan Z.

_______________________________________________
Devel mailing list
Devel на linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel



Подробная информация о списке рассылки Devel