53035 2025-02-11 21:35:41 +0300 Отвалилась поддержка /etc/emacs/site-start.el 2025-02-25 06:33:50 +0300 1 1 4 Development Sisyphus emacs unstable x86_64 Linux CLOSED FIXED P5 normal --- 1 manowar sbolshakov manowar savoptik sbolshakov qa-sisyphus oldest_to_newest 259064 0 manowar 2025-02-11 21:35:41 +0300 И, как следствие, /etc/emacs/site-start.d/*.el. А там было много ALT-специфичного. Просьба восстановить. 259065 1 manowar 2025-02-11 21:39:57 +0300 Насколько я понимаю, лечится это примерно вот так: # ln -s /etc/emacs/site-start.el /usr/share/emacs/30.0.93/site-lisp/ 259069 2 sbolshakov 2025-02-11 23:00:02 +0300 Не то чтоб сама собой взяла и отвалилась -- некто, сильно похожий на вашего покорного взял да и цинично отвалил. причина проста -- там червие (да, emacs-base, я смотрю на тебя). Для альт-специфики, если таковая и правда найдётся, есть /usr/share/emacs/site-lisp, а вот именно site-specific в смысле 'у меня на localhost' -- я сильно не уверен, что такое следует паковать. В общем, нет, я не хотел бы это восстанавливать -- но разумеется готов выслушать доводы в пользу. 259071 3 manowar 2025-02-11 23:48:45 +0300 (Ответ для 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/ надо бы пересмотреть --- вдруг там всё-таки есть что-то прекрасное. 259087 4 sbolshakov 2025-02-12 12:52:42 +0300 Зависимость на пакет 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) -- по возможности, откажитесь от этой идеи. 259094 5 manowar 2025-02-12 14:02:50 +0300 Заранее благодарю. Но тут ведь ещё какое дело? В пакете 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. Но это всегда выглядит как недоработка ("доработать напильником"). 259106 6 sbolshakov 2025-02-12 15:44:00 +0300 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. 259108 7 manowar 2025-02-12 16:21:34 +0300 > В вашем спеке кажется необходимым добавить 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. :) 259117 8 sbolshakov 2025-02-12 17:25:26 +0300 (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 и не морочиться. 259905 9 repository-robot 2025-02-25 06:33:50 +0300 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)