From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.help Subject: Re: Runtime package dependencies and compilation order Date: Tue, 31 May 2016 16:47:09 +0200 Message-ID: <87bn3mi8sy.fsf@web.de> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1464706247 30625 80.91.229.3 (31 May 2016 14:50:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 May 2016 14:50:47 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Boris Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue May 31 16:50:37 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 1b7l07-0002KU-Lz for geh-help-gnu-emacs@m.gmane.org; Tue, 31 May 2016 16:50:35 +0200 Original-Received: from localhost ([::1]:36783 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b7l06-0001UG-GV for geh-help-gnu-emacs@m.gmane.org; Tue, 31 May 2016 10:50:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b7kwx-0007cJ-0n for help-gnu-emacs@gnu.org; Tue, 31 May 2016 10:47:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b7kws-0001ot-Pl for help-gnu-emacs@gnu.org; Tue, 31 May 2016 10:47:17 -0400 Original-Received: from mout.web.de ([212.227.15.14]:58726) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b7kws-0001ob-FL for help-gnu-emacs@gnu.org; Tue, 31 May 2016 10:47:14 -0400 Original-Received: from drachen.dragon ([94.217.122.112]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0M9MDO-1bDmXx0IOM-00CiI2; Tue, 31 May 2016 16:47:11 +0200 In-Reply-To: (Boris's message of "Mon, 30 May 2016 09:05:00 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.94 (gnu/linux) X-Provags-ID: V03:K0:GIMBrYc8Vt+sXSwIuDoIFMjH7dNjgm62shN3QR27YGzU5h8j5DM RwrExt5pfke5EITO6GbWsdYmeJbi27VO+Im/ZrqGNNmTZfMbyaOS2tZiQQi4cW6Qc1vui8J xEzEETGahz3TbroB/sPFNWwBInCkkiewkjXxducmEc9gS0qxVux4wRZKHyYBZ9mGTdMRQlV aI7mbM7YKTbRRn+nVtpAw== X-UI-Out-Filterresults: notjunk:1;V01:K0:SQaaVx5cz4E=:vPLA+yTWtRuHDv/nJSrM55 54sfvi7HmHitMMixR9jcrIDtNtpfNWt+Hhk1Dwy3Ilog2UVrKuad71p0ak/lO2Au4VetBR+XP gi5uMtzAM7Z1B+ZGmRbMibpfW8oPpgCpQuVqijs1Ya3J2b6F4ixDOo6xWYaXrOqPx1YQ/mxPR K+BeIpyyLWGRjHycjFPhVtluCeTp2iQzjBA7dwPYpqmr7seP7z5tqh/B/ieXKAaGj8HlAkkcb e9+Ncbpiygojr5wWSSRczOUHI82hs7MrK6QmyXm+j3QfTPMaKtxEhbY9xi6J718tj8yR+uvWs u5gXgaf4Ce4jHYiVHCfb34KZpPu+NKtdMbJBgrcoXB7SOPze3y0S3Vcl/0jN32VruAdM/gcQN gdqlV0vg9w30mNVTVefnme9kJ2ASI8EoN1+M2VcI1GcTzQSnTvHSYUhzkbqqFbHm+chsDHTY1 a7/RBrgroadUEuhiMxloYDj/aoSzLJqEhHtcXkmcbDH+WpN1PMZtJai2Xe/lsZ7LppxjuD7Fx m8jywI6AXsvjwgwNA1+d7SKZ8z3Qa9tlA5quwKo1mM19/J1Tf1LnkF/O12svm20JTkILF6VSy RGLs3E4WsgFn6IDMugtDu8Z07lzpqG/a0Nt4F6R0QS4xTXvUWoVpLzAboAn2P9FWladq2BhCn DWm41kocg94AvFr6ejOjVS8Ah39JITgOdLlJSyD/f47hDLcdHJB4WOM8WKDF+ZVEyWErn18qR 5uVxnstDMnfaxo1BqJQDy71CNdFE5+7cnNCShCbdkHvTVihnyUbhcshAPoj/yPb4WmWltSnJ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.14 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.help:110147 Archived-At: Boris writes: > Recently I've faced following problem. I have a package A that might > depend on package B or (disjunction) package C. Is this an exclusive "or"? If not, why not just depend on B _and_ C? In the other case I cannot suggest anything better than what you already did. Since AFACT, Emacs package management doesn't (yet?) allow dependencies of type "X or Y" (unlike some OS). But I wonder... > The problem comes when someone wants to use the part of package A that > depends on package B - if package A is byte compiled before B, then some > functionality doesn't work and you have to manually recompile A. ...is really the compilation order a problem, or the fact that A had been compiled without B being _loaded_? Doesn't make much a difference from the end user's view, though. Regards, Michael.