emacs/xemacs i rpm 4.2 :>

[Artur Frysiak]

On Mon, Apr 07, 2003 at 05:19:16AM +0200, Tomasz Kłoczko wrote:
> 
> Strasznie jest tu zamieszane i coś z tym trzeba zrobić :>
> 
> Primo: w makrach rpm-a są makra %___emacs_lispdir_helper, %_emacs_lispdir 
> %_xemacs_lispdir. Pomijając już to, że sa one używane tylko w jesnym 
> miejscu (autoconf) to jeszcze są tak zaplątane ze chyba gorzej juz być nie 
> mogło :>

w autoconf.spec jest pilotażowo i wymaga jeszcze dopracowania.
Ogólnie zrobiłem to po to aby powstawały pakiety dla GNU emacsa i
XEmacsa.

> # (X)emacs support
> %___emacs_lispdir_helper  -batch -q -eval '(while load-path (princ (concat (car load-path) "\\n")) (setq load-path (cdr load-path)))' 2> /dev/null|sed -n '/\\(.*\\/x\\?emacs\\/site-lisp\\)\\/\\?$/{s,,\\1,p;q;}'
> %_emacs_lispdir %(emacs %___emacs_lispdir_helper)
> %_xemacs_lispdir %(xemacs %___emacs_lispdir_helper)
> 
> Koszmar .. :>
> Wiem chyba nawet skąd to się wzieło .. z aclocal.m4 z autoconfa (?)
> Tak czy inaczje to jest nieco chore i trzeba to prościej zrobić.

Nie dokładnie z aclocal.m4 ale z autoconfa.
Po co mam wymyślać coś co twórcy autoconfa już wielokrotnie testowali.

> Pierwsze ma wyłuskać ścieżkę z której emacs/xemacs ładują 
> automatycznie makra. Są przy tym używane jakieś sedy i dzikie węże o 
> ściezkę ustalaną w trakcie budowania xemasca przez:
> 
>         --package_path="~/.xemacs::%{_datadir}/%{name}-packages" \
> 
> Gdyby powyzsze zmienić na:
> 
>         --package_path="%{_datadir}/%{name}-packages" \

To i tak trzeba zmienić ponieważ "~/.xemacs" było rozwijane go
"/home/users/builder/.xemacs" co nie jest intencją autora.

> to o tą scieżkę możnaby odpytać poprzez poprostu:
> 
> $ xemacs -batch -q -eval '(princ configure-package-path)'
> 
> I to możnaby używać w pakietach dla xemacsa.
> Analoginie możnaby zrobić z emacsem.
> Bez wycinania "~/.xemacs::" możnaby i tak obrobić tylko to co powyższe 
> zwraca żeby wyłuskać powyżsża ścieżkę.
> Wydaje mi się też ę nie ma sensu z mocno pzreładowanywać makrami 
> globalnego zestawu makr rpm-a i ewentualne %{_xemasc-packagesdir} mogłby 
> być definiowane in situ tak jak to odbywa się przykładowo w pakeitach 
> modułami do xmms.

Nie uważam aby globalny zestaw był przeładowany. A powtarzanie tego w
wielu specach nie ma sensu bo może prowadzić do zwiększenia entropii
(sic!) i utrudnić prace nad pakietami.

> Nadal wydaje mi się ze zarówno emacs jak i xemacs maja jeszcze sporo
> śmieciaw w pakietach (choćby pliki Changelog.gz rozłożone w katalogach z 
> makrami).
> Wydaje mi się że także możnaby spróbować pozbyc się wersjinowania
> katalogów xemasca jak i emacsa. W obecnej wersji i tak nie można 
> zainstalować kilku xemacsów czy emacsów, a po każdym upgrade ze ziena 
> wersji pozostają po wszytkim puste katalogi (druga sprawa że nie powinny).

Wolna droga. Byle by tylko dalej działał XEmacs i dokumentacja
odzwierciedlała istniejącą sytuacje.

Pozdrawiam
-- 
wiget