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 10:28:27 -0500 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <87y8ildw10.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> <874ql9i60e.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 1096990231 5033 80.91.229.6 (5 Oct 2004 15:30:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 5 Oct 2004 15:30:31 +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 17:30:21 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 1CErGf-0005P1-00 for ; Tue, 05 Oct 2004 17:30:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CErNI-0000mx-Nx for ged-emacs-devel@m.gmane.org; Tue, 05 Oct 2004 11:37:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CErNA-0000mS-T3 for emacs-devel@gnu.org; Tue, 05 Oct 2004 11:37:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CErNA-0000m3-5k for emacs-devel@gnu.org; Tue, 05 Oct 2004 11:37:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CErNA-0000m0-2E for emacs-devel@gnu.org; Tue, 05 Oct 2004 11:37:04 -0400 Original-Received: from [66.93.216.237] (helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CErGC-0003Yp-AO; Tue, 05 Oct 2004 11:29:52 -0400 Original-Received: from trouble.defaultvalue.org (omen.defaultvalue.org [192.168.1.1]) by defaultvalue.org (Postfix) with ESMTP id B4E073FC9; Tue, 5 Oct 2004 10:29:51 -0500 (CDT) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id 21D93410A1; Tue, 5 Oct 2004 10:28:27 -0500 (CDT) Original-To: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Tue, 05 Oct 2004 10:53:14 -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:27940 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27940 Stefan Monnier writes: > Just as it is possible if you don't use packages, it should be > possible for the end user to decide that she wants to install Emacs > versions 20.3, 20.4, 21.1, 21.2, and 21.3. We probably could do that for many packages. Often it comes down to a decision based on the available manpower as compared to the value of providing additional revisions, though if all packages were to do it, it might also come down a decision based on the load on the infrastructure. It looks like we already provide over 15000 source packages just in testing and unstable, and the number of actual packages will be much more than that, related to the number of architectures we support. > Using package systems like `depot' or `stow', I haven't had any trouble > with any existing package. No need for special support from the > upstream developer. OK, well for now, I'm not familiar enough with them to meaningfully debate their merit as compared to apt, dpkg, and Debian's current policies. > You don't need to change the name, just the directory in which to > search for the lib. The problem is that then -L linking will fail unless ld.so has also been augmented with these paths, or unless the user has added that directory to their LD_LIBRARY_PATH. I'd still like to see dlpen support for the algorithm that the normal linker uses, so you can tell dlopen to open libbar version 4, and let it find the latest suitable revision (i.e. the same one -L linking would find at runtime). In any case, I suppose this is all somewhat off-topic. The only plea I'd like to make is that if possible, Emacs use some versioning strategy where there's at least one number or numbers that changes iff substantial backward compatibility is introduced. -- 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