bug#19564: 24.4; eieio backward compatibility

[Ivan Shmakov <ivan@siamics.net>]

>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
>>>>> On Tue, 13 Jan 2015 15:50:48 +0100 Thierry Volpiatto wrote:
>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:

[…]

 TZ> Forgive my ignorance: is that compatibility guaranteed or
 TZ> beneficial?

 TV> No, but that's mean that now with these recent changes all people
 TV> using helm will have errors in their helm packages when switching
 TV> emacs-version until they reinstall all; And for sure they will not
 TV> reinstall and I expect tons of bugreport in next weeks... (I
 TV> crossfingers hoping I am wrong)

 TZ> Maybe Emacs needs a shell-level way to recompile all or some
 TZ> installed packages?

	The approach used in Debian is that the Debian “binary” packages
	contain only the source code (.el), and the respective
	byte-compiled (.elc) files are produced at the installation
	time, – for /each/ of the installed Emacs versions.

	So, when, say, gnugo.el is installed, in addition to
	/usr/share/emacs/site-lisp/gnugo.el, the following files may
	also appear on the filesystem (depending on the versions of
	Emacs installed on the system):

/usr/share/emacs25/site-lisp/gnugo.elc
/usr/share/emacs24/site-lisp/gnugo.elc
/usr/share/emacs23/site-lisp/gnugo.elc
…

	I’m not sure whether Emacs itself handles it well when it comes
	to, say, C-h f.  And frankly, for backup purposes, I’d rather
	prefer all that to go under /var/cache instead.  (And the same
	for __pycache__, etc.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A