Summary: | elisp-common.eclass: 00site-gentoo.el breaks order for nxml | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin von Gagern <Martin.vGagern> |
Component: | Eclasses | Assignee: | Emacs project <emacs> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | ||
Priority: | High | ||
Version: | 2007.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | site-gentoo.el |
Description
Martin von Gagern
2008-02-19 22:18:44 UTC
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. |