From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.devel Subject: Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.] Date: Tue, 05 Oct 2004 09:39:13 -0500 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <874ql9i60e.fsf@trouble.defaultvalue.org> References: <1096291271.415813c757a26@imp6-q.free.fr> <20040927134714.GA20012@fencepost> <87hdphx91c.fsf@trouble.defaultvalue.org> <87655wswkv.fsf@trouble.defaultvalue.org> <871xgejdk7.fsf@trouble.defaultvalue.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1096987324 28127 80.91.229.6 (5 Oct 2004 14:42:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 5 Oct 2004 14:42:04 +0000 (UTC) Cc: Francesco Potorti` , rms@gnu.org, Jerome Marant , emacs-devel@gnu.org, "Kim F. Storm" , Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 05 16:41:47 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CEqVe-0000c6-00 for ; Tue, 05 Oct 2004 16:41:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CEqcI-0004lu-0S for ged-emacs-devel@m.gmane.org; Tue, 05 Oct 2004 10:48:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CEqcB-0004lp-2p for emacs-devel@gnu.org; Tue, 05 Oct 2004 10:48:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CEqcA-0004lS-9e for emacs-devel@gnu.org; Tue, 05 Oct 2004 10:48:30 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CEqcA-0004lP-77 for emacs-devel@gnu.org; Tue, 05 Oct 2004 10:48:30 -0400 Original-Received: from [66.93.216.237] (helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CEqUZ-0004I2-1t; Tue, 05 Oct 2004 10:40:39 -0400 Original-Received: from trouble.defaultvalue.org (omen.defaultvalue.org [192.168.1.1]) by defaultvalue.org (Postfix) with ESMTP id 0DE583FC9; Tue, 5 Oct 2004 09:40:38 -0500 (CDT) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id B064D410A1; Tue, 5 Oct 2004 09:39:13 -0500 (CDT) Original-To: Stefan In-Reply-To: (monnier@iro.umontreal.ca's message of "Tue, 05 Oct 2004 07:26:16 -0400") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27937 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27937 Stefan writes: > While I mostly agree that we should change emacs-major-version for > non-bug-fix releases, I think that limitations of specific packaging > systems are not a motivating factor. Perhaps not for you, though upstream can be a *great* help when their versioning behaves sanely. > I actually think that your problems should cause you to reconsider > the design of the packaging system since such problems surely happen > with other packages as well. I'm not sure what kind of improvements you're suggesting, and for which kinds of problems, but I don't recall a situation where we *can't* accomodate multiple installs of something in Debian. It's just a matter of how much hassle it is and how far we have to diverge from the upstream code, and that's usually determined by how much attention the upstream developers have paid to the issue. (It's also, depending on the package, a question of manpower.) For example, if emacs started making releases with major breakage that only bumped the third version number, i.e. 21.4.1, then (as Jerome suggests) we'd just have to start releasing emacs packages which include all three versions: emacs21.4.1. All that said, by all means, if you can suggest improvements, please do. > Stefan "who's generally disappointed by the poor support for > multiple concurrently installed versions of a single package > in most package systems" This blame (though not generally in the case of emacs) may lay as much at the feet of the upstream developers as the downstream packagers (speaking as one who works on both sides). If the upstream hasn't ever considered the problem, then it can be very difficult, and require substantial hacking, to alter the upstream to handle multiple installed versions. This can be further hindered by the available OS and tools. For example, the fact that dlopen doesn't support versioning the way that ld.so does can make it difficult to allow multiply installed versions of software that relies on dlopened libraries, unless the upstream has considered that problem and chosen suitably unique library *names* for those libraries. The more classic example is an upstream that doesn't bump its library soname versions when making backward incompatible changes to the code. This can be a big problem. All of these examples assume that the distribution is going to try to conform to the FHS. If you're willing to ignore that, then you may have other options. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4