From mboxrd@z Thu Jan 1 00:00:00 1970
Path: news.gmane.org!not-for-mail
From: Philipp Stephani
Newsgroups: gmane.emacs.help
Subject: Updating Elisp files while Emacs is running
Date: Mon, 14 Mar 2016 13:41:17 +0000
Message-ID:
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-Trace: ger.gmane.org 1457962904 15757 80.91.229.3 (14 Mar 2016 13:41:44 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Mon, 14 Mar 2016 13:41:44 +0000 (UTC)
To: "help-gnu-emacs@gnu.org"
Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Mar 14 14:41:43 2016
Return-path:
Envelope-to: geh-help-gnu-emacs@m.gmane.org
Original-Received: from lists.gnu.org ([208.118.235.17])
by plane.gmane.org with esmtp (Exim 4.69)
(envelope-from )
id 1afSkf-0006NP-SA
for geh-help-gnu-emacs@m.gmane.org; Mon, 14 Mar 2016 14:41:42 +0100
Original-Received: from localhost ([::1]:41056 helo=lists.gnu.org)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from )
id 1afSke-0000ai-P7
for geh-help-gnu-emacs@m.gmane.org; Mon, 14 Mar 2016 09:41:40 -0400
Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44545)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from ) id 1afSkU-0000ac-0y
for help-gnu-emacs@gnu.org; Mon, 14 Mar 2016 09:41:31 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from ) id 1afSkS-0004GJ-NH
for help-gnu-emacs@gnu.org; Mon, 14 Mar 2016 09:41:29 -0400
Original-Received: from mail-lb0-x22c.google.com ([2a00:1450:4010:c04::22c]:35353)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from ) id 1afSkS-0004GC-AE
for help-gnu-emacs@gnu.org; Mon, 14 Mar 2016 09:41:28 -0400
Original-Received: by mail-lb0-x22c.google.com with SMTP id bc4so239087999lbc.2
for ; Mon, 14 Mar 2016 06:41:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to;
bh=Hje8xmBR76zFyb1oX68wSfjWN27hlS/SK65u7CuZ3nk=;
b=p+FiJb/GPUD1vuW1YDL3PzA3qO09KxGtN6PaSRlx59bjhsTeo7Wc8LNmwnbg6h6tMa
m5c5lu6/82zMDKWRn0glctgnanI0ecwztnJTGAweuxofzuVnXOhumEkacScYHN4aGqn6
R5EjxnkCHVPD8mbE8ezJyRue2q454uQEMG3APWB9LISBUXwpH3sD6M6Kc3vPw5yQO+Vf
zTcrMuZ9xulVIsJ0h4f0FAL4WxU5Diy12qX7R8DGiSxmiZNR61abqqhSOzkp2YvURu9i
BASLJ0NWSh2FGT9tRUEDeuUr7/Q24Ih0UDHniMZi3bI5cdfgTV9S3y3/0Iae0kGhBdG2
TQfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=Hje8xmBR76zFyb1oX68wSfjWN27hlS/SK65u7CuZ3nk=;
b=LjxXGl10m849nqnoscZXW9oZe6cQkyUCfW+IHMYmHx+iiLy4bIuQcOgB0REherBnhx
AOnyywPioCAKlmSzuPpubKy3UfbBxOyjpeMrwKPu6+KUS52e7ry7K25JE1abdGc0rm8R
ACDD/trnBJrwcrt0fGCYr1M/cgGNC28B+4U+MHwpT/Aedaj6LQorqLm5QfX10Xapre6A
ThBq9vtOqHdA4BKJ/lyiaVzfXscywQgAUGceYs0BDdg0wYRCtPBNLQUqrYz+7no9Wj5A
vwhcC+NmRBA6xAZuWK3ciU7r8I7znCQMywC+kJgkixQLFLetVDE1PY3yketFVXTbwctd
GmMQ==
X-Gm-Message-State: AD7BkJKHtwQWNlXj27WRVjcW8IOFE4eDME6spmc6J7PyqU7UXDxD3fB2vnnRdrKKTpSC1oKQNm+aTIUXc+n40g==
X-Received: by 10.25.151.135 with SMTP id z129mr6362815lfd.122.1457962887099;
Mon, 14 Mar 2016 06:41:27 -0700 (PDT)
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2a00:1450:4010:c04::22c
X-Content-Filtered-By: Mailman/MimeDel 2.1.14
X-BeenThere: help-gnu-emacs@gnu.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Users list for the GNU Emacs text editor
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org
Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org
Xref: news.gmane.org gmane.emacs.help:109567
Archived-At:
Hi,
OS-level package managers such as Debian's dpkg generally replace files
unconditionally when upgrading. Typically this is not a problem because
running binaries will continue to use the in-memory image, and daemons can
get restarted or sent a signal without user interaction. However, for Emacs
the situation seems different: Emacs not only needs its (dumped) binary,
but also relies on Elisp files. For Elisp files already loaded when the
upgrade is running this typically doesn't cause problems, but when Elisp
files aren't already loaded, replacing them causes problems because the
directories containing them are versioned (see e.g. lispdir in configure.ac),
so that when the version changes (even for minor changes, such as updating
from the recent pretest-1 to pretest-2), the files are no longer at the
expected location, and libraries can't be loaded any more, either manually
or via autoloads. Similar things happen for system-wide ELPA packages (in
the package-directory-list directories), because the names of these
directories are also versioned. How could this be changed so that
unattended upgrades changing the Emacs version are possible while Emacs is
running? Could the Elisp file directories get names that don't include the
version number (maybe hidden behind a configure option)? Is it possible to
install system-wide ELPA packages into directories that don't contain
version numbers? Or is there another way, e.g. using a signal to
reinitialize the load-path and the package system? I'm aware these
suggestions would still cause issues if e.g. Elisp files get moved around
or the byte code format changes, but that seems to be comparatively rare.
Thanks,
Philipp