When emerge'ing the mailcrypt package, the build will overwrite the /usr/share/emacs/site-lisp/site-start.el file the user has installed! This is not good, particularly not, because the entry in the newly created file is not necessary! Emacs will find all elisp files in the /usr/share/emacs/site-lisp directory tree anyway; there is no nood to set the load-path explicitely.
okay i was unaware of this and it wasnt caught during the months the app-emacs category was outside of portage being beta-tested. i guess there a few issues: 1. nearly every ebuild in app-emacs/ uses site-start.el the place to add hooks, set variables, paths and other config information etc. 2. you said the users site-start.el is overwritten. this is true for any app-emacs/ package, as site-start.el is regerated after an app-emacs/ package is installed or uninstalled. 3. if emacs doesn't require me adding the load-path settings each time, then i'll definately remove that if you have your own site-start.el, perhaps i can add something like a /etc/emacs/site-start.el which /usr/share/emacs/site-lisp/site-start.el (the portage generated one) will load first? comments? Matt
Sorry for the long delay in answering this! I couldn't make it any earlier, I'm afraid. Concerning your second point: I do have a pretty sophisticated Emacs installation, which I -- as of now -- maintained manually. When I installed a new laptop, I was using the mailcrypt package from Gentoo for the first time, because I figured, I might as well try whether the Gentoo installation works. That's why I didn't have this problem with any other package yet. :-) As for possible solutions: Would it be possible to CONFIG_PROTECT the site-start.el file, so that etc-update shows me changes and let's me resolve it? If the file had to be moved to /etc for this purpose, it would be alright for me, though this would complicate matters IMHO a bit. Having an /etc/emacs/site-start.el file in addition to the one in /usr/share/emacs/site-lisp would be fine also. Then the installation could add an appropriate site-start.el file in the latter location when Emacs is installed, but the user would be free to modify it without breaking anything. Either way is fine for me ... I think, though, that just config-protecting the file in /usr/share/emacs/site-lisp would be the best solution.
assigned
Is there anything happening on this front? I am asking because I just converted my site-lisp installation to use the Gentoo packages rather than my own ones, so I came across this problem one more time. For the moment I fixed the problem for me by renaming my own site-start.el file to 00local-site-start.el, so that the ebuilds will include my file into the generated file again. This works fine ... But there should be a _standard_ (read: documented) way of handling this. Also, it would be nice to have an "elisp-update" command that performs the re-build of the site-start.el file; just like "env-update" does for the profile scripts.
I think having a /etc/emacs/site-start.el would be the best solution, since it's already protected by CONFIG_PROTECT. The problem with adding /usr/share/emacs/site-lisp/site-start.el to CONFIG_PROTECT is that it's going to become unwieldy if we keep adding files and directories to it.
/etc/emacs is fine with me! That's where config files should go to anyway. :-)
while you're at it. could you please upgrade to mailcrypt 3.5.8 which has been available since september? the same ebuild script works just fine. Thanks a lot.
Should we close this bug? (portage doesn't override /usr/share/emacs/site-lisp/site-start.el anymore. Instead, it creates /usr/share/emacs/site-lisp/site-gentoo.el every time you install elisp packages)
Yes, it should be closed.
