[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Emacs (i386-mingw-nt5.1.2600) of 2008-08-06 on LENNART

From: Giorgos Keramidas
Subject: Re: GNU Emacs (i386-mingw-nt5.1.2600) of 2008-08-06 on LENNART-69DE564 (patched): error "Required feature `diary-loaddefs' was not provided"
Date: Sun, 10 Aug 2008 05:08:14 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix)

On Sat, 09 Aug 2008 23:50:16 +0200, Lennart Borgman wrote:
>>> C:\Dokumente und Einstellungen\Rainer>c:\Emacs23\emacs\bin\emacs -q -batch 
>>> -f list-load-path-shadows
>>> Adding c:/Emacs23/EmacsW32/lisp/ to load-path
>>> This site has duplicate Lisp libraries with the same name.
>>> If a locally-installed Lisp library overrides a library in the Emacs
>>> release,
>>> that can cause trouble, and you should probably remove the locally-installed
>>> version unless you know what you are doing.
>>> c:/Emacs23/emacs/lisp/vc-dav hides c:/Emacs23/emacs/lisp/url/vc-dav
>>> 1 Emacs Lisp load-path shadowing was found
> Thanks Rainer,
> That is probably something left over from an older installation of
> Emacs. Could you perhaps try to delete or rename the c:/Emacs23/
> directory and install Emacs again?


>> You should take care of this, but I don't think it's related to your
>> original problem.
> It is a bit related to the installer for Emacs+EmacsW32 that I
> distribute. I have written it so that it does not delete the old Emacs
> tree, but I think that is a mistake.
> I think I will let it delete the emacs directory before installation. It
> should be (rather) safe since a user should not put files there.
> Any thoughts on this?

Hi Lennard,

First of all, a big thank you for making Windows builds of Emacs.  I
always download your builds and install them when I am forced to work on
Windows, because I can't stand most of the other Windows editors :-)

I don't really know much about the internals of the Windows installers
of the packaging system of Windows, but let me describe an idea that may
be useful.

You could modify the installer to

  (1) perform pre-installation checks.  When it finds an existing
      installation it can prompt the user that "An existing Emacs
      installation has been found.  Please uninstall it first, and rerun
      this installer."

  (2) Only remove the files that the installer itself added to the
      system (i.e. by using some sort of "packaging list").

This is similar to what the package installation tools of FreeBSD too.
When there are directories in the packaging list, we use one of two
directives to remove them, either address@hidden' or address@hidden'.  For those
directories that the user is not supposed to manually add files, we use
address@hidden' in the packaging list, and we remove the directories in
depth-first order, i.e.:

  @dirrm %%DATADIR%%/%%EMACS_VER%%/etc/images/gud
  @dirrm %%DATADIR%%/%%EMACS_VER%%/etc/images/gnus
  @dirrm %%DATADIR%%/%%EMACS_VER%%/etc/images/ezimage
  @dirrm %%DATADIR%%/%%EMACS_VER%%/etc/images/custom
  @dirrm %%DATADIR%%/%%EMACS_VER%%/etc/images
  @dirrm %%DATADIR%%/%%EMACS_VER%%/etc/gnus
  @dirrm %%DATADIR%%/%%EMACS_VER%%/etc/e
  @dirrm %%DATADIR%%/%%EMACS_VER%%/etc/charsets
  @dirrm %%DATADIR%%/%%EMACS_VER%%/etc
  @dirrm %%DATADIR%%/%%EMACS_VER%%

For the directories that may have user data or may be shared among
multiple packages, we use address@hidden' and remove those in depth-first
order too, i.e.:

  @dirrmtry share/icons/hicolor/128x128/apps
  @dirrmtry share/icons/hicolor/128x128
  @dirrmtry share/icons/hicolor
  @dirrmtry share/icons
  @dirrmtry share/applications
  @dirrmtry var/games/emacs
  @dirrmtry var/games
  @dirrmtry var

The packaging list format is quite `simple'.  It lists files by their
relative pathname under ${LOCALBASE} (which defaults to `/usr/local'),
and any line starting with `@' is a special `packaging directive'.
Parts of the packaging list for the `editors/emacs-devel' port look like

  @dirrm %%DATADIR%%/%%EMACS_VER%%/site-lisp
  @dirrm %%DATADIR%%/%%EMACS_VER%%/lisp/url
  @dirrm %%DATADIR%%/%%EMACS_VER%%/lisp/textmodes
  @dirrm %%DATADIR%%/%%EMACS_VER%%/lisp/term
  @dirrm %%DATADIR%%/%%EMACS_VER%%/lisp/progmodes
  @dirrm %%DATADIR%%/%%EMACS_VER%%/lisp/play
  @dirrm %%DATADIR%%/%%EMACS_VER%%/lisp/org
  @dirrm %%DATADIR%%/%%EMACS_VER%%/lisp/obsolete
  @dirrm %%DATADIR%%/%%EMACS_VER%%/lisp/nxml
  @dirrm %%DATADIR%%/%%EMACS_VER%%/etc
  @dirrm %%DATADIR%%/%%EMACS_VER%%
  @dirrm libexec/emacs/%%EMACS_VER%%/%%EMACS_ARCH%%
  @dirrm libexec/emacs/%%EMACS_VER%%
  @dirrm libexec/emacs
  @dirrmtry share/icons/hicolor/scalable/mimetypes
  @dirrmtry share/icons/hicolor/scalable/apps
  @dirrmtry share/icons/hicolor
  @dirrmtry share/icons
  @dirrmtry share/applications
  @dirrmtry var/games/emacs
  @dirrmtry var/games
  @dirrmtry var

By removing only the files that the Windows installer itself has
installed (as they are listed in the packaging list), we can keep any
site-lisp code or other local files.  By asking for an uninstall before
a new clean install is done, you would be pretty sure that only the
files of the new installation are present (and any local `site-lisp'

By keeping the list of address@hidden' directories small, you, as the
installer developer, can also add checks about modifications in the rest
of the installation tree.  If a directory is listed as address@hidden' but it
is not empty after you remove the files listed in your packaging list,
then there are local changes in that directory.  At that point, you have
the option of notifying the user that they have made local changes to
`internal' Emacs files, and prompt them for one of several things.
I've listed the options in decreasing order of what I would prefer, but
please feel free to implement any subset of them:

  * Keep a backup copy of the extra files, and then delete them.  Point
    the user to the backup copy of the files, so they can look later for
    any interesting bits and reinstall them manually.

  * Just delete the files, and let future installs run on a clean slate.

  * Abort the installation, and log the mismatched packaging list
    entries to a text file on the disk.  Pointing the user to the log
    file, so they can manually "fix" the installation directory would be
    useful too.

Now I admit that I don't really know how much work it would be to do
something similar for the Windows build of Emacs.  But if it's useful
then I'm glad :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]