Насколько я понимаю, лечится это примерно вот так:
# ln -s /etc/emacs/site-start.el /usr/share/emacs/30.0.93/site-lisp/

Не то чтоб сама собой взяла и отвалилась -- некто, сильно похожий на вашего покорного
взял да и цинично отвалил. причина проста -- там червие (да, emacs-base, я смотрю на тебя).
Для альт-специфики, если таковая и правда найдётся, есть /usr/share/emacs/site-lisp,
а вот именно site-specific в смысле 'у меня на localhost' -- я сильно не уверен,
что такое следует паковать.
В общем, нет, я не хотел бы это восстанавливать -- но разумеется готов выслушать
доводы в пользу.

(Ответ для Sergey Bolshakov на комментарий #2)
> Для альт-специфики, если таковая и правда найдётся, есть
> /usr/share/emacs/site-lisp

Именно отсюда и началось моё исследование проблемы:

$ emacs --batch --eval '(print (string-join load-path))'

"/usr/lib64/emacs/30.0.93/site-lisp/usr/share/emacs/30.0.93/site-lisp/usr/share/emacs/30.0.93/lisp/usr/share/emacs/30.0.93/lisp/vc/usr/share/emacs/30.0.93/lisp/use-package/usr/share/emacs/30.0.93/lisp/url/usr/share/emacs/30.0.93/lisp/textmodes/usr/share/emacs/30.0.93/lisp/progmodes/usr/share/emacs/30.0.93/lisp/play/usr/share/emacs/30.0.93/lisp/org/usr/share/emacs/30.0.93/lisp/nxml/usr/share/emacs/30.0.93/lisp/net/usr/share/emacs/30.0.93/lisp/mh-e/usr/share/emacs/30.0.93/lisp/mail/usr/share/emacs/30.0.93/lisp/leim/usr/share/emacs/30.0.93/lisp/language/usr/share/emacs/30.0.93/lisp/international/usr/share/emacs/30.0.93/lisp/image/usr/share/emacs/30.0.93/lisp/gnus/usr/share/emacs/30.0.93/lisp/eshell/usr/share/emacs/30.0.93/lisp/erc/usr/share/emacs/30.0.93/lisp/emulation/usr/share/emacs/30.0.93/lisp/emacs-lisp/usr/share/emacs/30.0.93/lisp/cedet/usr/share/emacs/30.0.93/lisp/calendar/usr/share/emacs/30.0.93/lisp/calc/usr/share/emacs/30.0.93/lisp/obsolete"

Как можно видеть, тут нет ни одного /usr/share/emacs/site-lisp:

$ emacs --batch --eval '(print (string-join load-path))' | grep '/usr/share/emacs/site-lisp' | wc -l
0

А это значит, что паковать модули нужно в /usr/share/emacs/<версия>/site-lisp. Что это означает? Что теперь официально любой код считается привязанным к версии Emacs? Если да, то почему так?

Во-вторых, если бы /usr/share/emacs/site-lisp всё ещё был в load-path, то тогда (насколько я понимаю)  работал бы и /usr/share/emacs/site-lisp/site-start.el, который как раз указывает на /etc/emacs/site-start.el:

$ ls -l /usr/share/emacs/site-lisp/site-start.el 
lrwxrwxrwx 1 root root 35 сен 27  2022 /usr/share/emacs/site-lisp/site-start.el -> ../../../../etc/emacs/site-start.el

Способ "циничного отвала" в чём заключался? В том, что удалили /usr/share/emacs/site-lisp из load-path? Или я ошибаюсь?

У меня два вопроса:

1. Первый уже озвучил: куда теперь паковать код, независимый от версии Emacs?
2. Куда запаковать *.el скрипт, который выполнится при старте Emacs в нашей обычной установке (то есть, если пользователь ничего специально не намудрил)?

А старый код, который в /etc/emacs/site-start.d/ надо бы пересмотреть ---  вдруг там всё-таки есть что-то прекрасное.

Зависимость на пакет emacs-base была исключена в emacs-28.2-alt3;
locallisppath, включающий только версионированные site-lisp, появился в emacs-29.1-alt2.
Восстанавливать зависимость на emacs-base я не намерен, но вернуть неверсионированный site-lisp пожалуй можно, хотя его ценность мне представляется неочевидной.

Дело в том, что, начиная с того же emacs-28.2-alt3, у нас включена native compilation,
результат которой зависит не только от версии emacs, но даже от flavour его сборки --
см.напр. пути с native-lisp. Как следствие, сторонние пакеты, содержащие *el,
могут быть собраны с natcomp для каждой пары version-flavour, либо без natcomp -- но тогда включится jit natcomp в пользовательский кэш при первой попытке использования.

Кроме этого, я не уверен, что всякий *el из стороннего пакета следует вообще паковать --
часто такие *el безнадёжно устарели в сравнении с тем, что доступно напр. с melpa,
и для пользователей преднастроенных конфигураций вроде doomemacs/spacemacs потенциально
могут представлять источник проблем.

Суммируя, я пожалуй верну неверсионированный site-lisp в следующей сборке, но мой ответ на 1) и особенно 2) -- по возможности, откажитесь от этой идеи.

Заранее благодарю. Но тут ведь ещё какое дело? В пакете rpm-build-emacs есть чудесная инструкция: (https://git.altlinux.org/srpms/r/rpm-build-emacs.git?p=rpm-build-emacs.git;a=blob;f=README.ALT.ru.txt;h=6f410d0c1a1b0f9adf89b304863edb044eac49ab;hb=da2bd2d6d624a7867a763ead7bfba832e5656145). Я был так очарован тем, что она на русском языке, что сразу прочитал и всё сделал как там написано. :)

Речь про пакет speechd-el. Вот его спек: https://git.altlinux.org/gears/s/speechd-el.git?p=speechd-el.git;a=blob;f=.gear/speechd-el.spec;h=59bcee379c6568b9eb0ca7f24112bb38df292e8d;hb=1f25867067b765ed4486495cf699064ea4a4a8e4 .

В частности, я положил *.elc в %_emacslispdir/, а старт-скрипт в %_emacs_sitestart_dir/. Если будет принято решение паковать всё в /usr/share/emacs/<версия>/site-lisp/, то нужно %_emacslispdir переопределить (и туда же добавить %_emacsversion, получается?).

> Дело в том, что, начиная с того же emacs-28.2-alt3, у нас включена native compilation,
> результат которой зависит не только от версии emacs, но даже от flavour его сборки

Да, это я заметил и поэтому положил *.eln вот сюда: %_libdir/emacs/%emacs_version/native-lisp/%emacs_version-*/ (%emacs_version пришлось вычислять отдельно в этой же спеке). Я думаю, что для этого пути тоже нужно добавить сразу готовый макрос.

В целом, я готов сам обновить пакет с макросами, но для этого нам нужно определиться с актуальными путями: какие они будут — с версией или без версии. Нативный, ясное дело, с версией.

> Суммируя, я пожалуй верну неверсионированный site-lisp в следующей сборке, но мой ответ
> на 1) и особенно 2) -- по возможности, откажитесь от этой идеи.

От возможности site-start не хотелось бы отказываться. В частности, для пакета speechd-el задача в том, чтобы говорилка сразу заговорила при запуске emacs, если speechd-el установлен. А как это сделать без site-start? Конечно, можно написать для пользователя инструкцию как и что настроить у себя в ~/.emacs. Но это всегда выглядит как недоработка ("доработать напильником").

wrt содержимого rpm-build-emacs -- ну да, по прошествии двадцати лет оно нуждается в некотором обновлении. Было бы неплохо, например, написать понятными всякому усердному
майнтайнеру (исключая присутствующих), что рефлекс 'вижу *el -- кладу в site-lisp' полезен вовсе не всегда, а случай speechd как раз и является исключением, подтвержадющим
правило, когда site-start уместен. Очевидно также, что для такого применения site-start
незачем находиться по версионированному пути.

В вашем спеке кажется необходимым добавить requires: emacs-base или какой-то похожий
пакет, содержащий /usr/share/emacs/site-lisp/site-start.el; собственно, этот файл мог бы содержаться и в самом speechd-el, как по мне.

А вот это:
%_libdir/emacs/%emacs_version/native-lisp/%emacs_version-*/*.eln
будет работать, если у пользователя установлен тот же бинарь emacs (с тем же хешем), что и при сборке, что приводит нас к необходимости собирать под все три или не собирать
нативно вообще -- я уж не говорю о том, что собранное таким образом дополнение
к emacs вообще-то должно бы требовать 3x emacs-%flavour == EVR, что со временем
добавит головной боли при обновлении самого emacs.

> В вашем спеке кажется необходимым добавить requires: emacs-base или какой-то похожий
пакет, содержащий /usr/share/emacs/site-lisp/site-start.el;

Пока что наличие /usr/share/emacs/site-lisp/site-start.el не играет роли. Требуется /usr/share/emacs/30.0.93/site-lisp/site-start.el. Ждём возвращения 
/usr/share/emacs/site-lisp в load-path, я правильно понимаю?

> собственно, этот файл мог бы содержаться и в самом speechd-el, как по мне.

Хм... Но тогда возможен конфликт с emacs-base. Ну, теоретически. Конечно, если в обоих пакетах будет идентичный симлинк, то конфликта не будет. Но мало ли, кто-то захочет поменять этот файл в emacs-base. :)

(In reply to manowar@altlinux.org from comment #7)
> > В вашем спеке кажется необходимым добавить requires: emacs-base или какой-то похожий
> пакет, содержащий /usr/share/emacs/site-lisp/site-start.el;
> 
> Пока что наличие /usr/share/emacs/site-lisp/site-start.el не играет роли.
> Требуется /usr/share/emacs/30.0.93/site-lisp/site-start.el. Ждём возвращения 
> /usr/share/emacs/site-lisp в load-path, я правильно понимаю?
Рано или поздно. Изменение тривиально, но и emacs-30.1 не за горами.

> > собственно, этот файл мог бы содержаться и в самом speechd-el, как по мне.
> 
> Хм... Но тогда возможен конфликт с emacs-base. Ну, теоретически. Конечно,
> если в обоих пакетах будет идентичный симлинк, то конфликта не будет. Но
> мало ли, кто-то захочет поменять этот файл в emacs-base. :)

Я имел ввиду, этому файлу вовсе незачем быть симлинком в etc.
То, что в спеке складывается heredoc'ом в speechd.el, можно было бы
сложить в site-start.el и не морочиться.

emacs-30.1-alt1 -> sisyphus:

 Mon Feb 24 2025 Sergey Bolshakov <sbolshakov@altlinux> 30.1-alt1
 - 30.1 released (fixed: CVE-2024-53920, CVE-2025-1244)
 - readd non-versioned site-lisp directory (closes: 53035)