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