Loading /usr/share/emacs/site-lisp/00site-gentoo.el (source)... An error has occurred while loading `~/.emacs': Symbol's value as variable is void: rng-schema-locating-files-default /usr/share/emacs/site-lisp/00site-gentoo.el contains these lines: ;;; nxml-gentoo-schemas site-lisp configuration ;; This must come after the nxml-mode site initialisation, ;; because rng-schema-locating-files-default is set there. (add-to-list 'rng-schema-locating-files-default "/usr/share/emacs/etc/nxml-gentoo-schemas/schemas.xml") However 00site-gentoo gets loaded before 50nxml-mode-gentoo.el. The lines seem to come from site-gentoo.d/60nxml-gentoo-schemas-gentoo.el which comes from app-emacs/nxml-gentoo-schemas-20080204 and would be in correct order. elisp-common.eclass seems to build 00site-gentoo from all the files in site-gentoo.d, breaking ordering requirements between directories. OK, my loading of individual [0-9][0-9]*-gentoo.el files is probably nonstandard, but looking at site-gentoo.el, the order is still wrong.
Please attach your /usr/share/emacs/site-lisp/site-gentoo.el
Created attachment 144021 [details] site-gentoo.el (In reply to comment #1) > Please attach your /usr/share/emacs/site-lisp/site-gentoo.el Here you are. Search for nxml. nxml-gentoo-schemas starts in line 98, nxml in 234.
Indeed. We are currently in a transition period, where we migrate the site-init files of individual packages from site-lisp/ to the site-lisp/site-gentoo.d/ directory. The currect elisp-common.eclass should handle all cases with files in both directories correctly; this is done by the sort routine in elisp-site-regen (search for "straight insertion sort"). However, previous versions of elisp-common.eclass are (naturally) not aware of the new site-gentoo.d directory. So, whenever elisp-site-regen from an old eclass version gets called, the site-init information of packages already in site-gentoo.d would be missing. Therefore we have added the 00site-gentoo.el auxiliary file which is just a concatenation of the individual files in site-gentoo.d. This file will be found by the old eclass version, which will include it at the beginning of site-gentoo.el. Unfortunately, it doesn't help if the newest eclass version is in the Portage tree; the version of the eclass at the time of the original merge will be saved together with the package in the VDB and is called by pkg_postrm when the package is unmerged (or updated). I don't see any way how we could fix this problem. We were aware that the ordering might not be preserved in all cases when we committed the eclass. This seemed acceptable, because (after converting most initialisations to autoload) there are only very few interdependencies between packages' site-init files. As a workaround, you may run "emacs-updater" which reinstalls all packages with site-init files still in the old location.
