From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Version naming Date: Sun, 19 Oct 2014 12:53:03 -0500 Message-ID: <85tx30osjk.fsf@stephe-leake.org> References: <8738ap3qgq.fsf@trouble.defaultvalue.org> <20141016095111.631bf393@anarchist.wooz.org> <85wq7xcbxe.fsf@stephe-leake.org> <851tq4ree5.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1413741210 12735 80.91.229.3 (19 Oct 2014 17:53:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Oct 2014 17:53:30 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 19 19:53:21 2014 Return-path: Envelope-to: ged-emacs-devel@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 1XfufQ-0001qU-NM for ged-emacs-devel@m.gmane.org; Sun, 19 Oct 2014 19:53:20 +0200 Original-Received: from localhost ([::1]:40786 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfufQ-0004eL-2K for ged-emacs-devel@m.gmane.org; Sun, 19 Oct 2014 13:53:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfufG-0004eC-M7 for emacs-devel@gnu.org; Sun, 19 Oct 2014 13:53:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XfufA-0002dj-P1 for emacs-devel@gnu.org; Sun, 19 Oct 2014 13:53:10 -0400 Original-Received: from dnvrco-outbound-snat.email.rr.com ([107.14.73.225]:21519 helo=dnvrco-oedge-vip.email.rr.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfufA-0002db-JR for emacs-devel@gnu.org; Sun, 19 Oct 2014 13:53:04 -0400 Original-Received: from [70.94.38.149] ([70.94.38.149:50843] helo=TAKVER) by dnvrco-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id EB/3F-27958-F7AF3445; Sun, 19 Oct 2014 17:53:03 +0000 In-Reply-To: (Stefan Monnier's message of "Sat, 18 Oct 2014 22:47:40 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (windows-nt) X-RR-Connecting-IP: 107.14.64.142:25 X-Authority-Analysis: v=2.1 cv=L8aTQoj8 c=1 sm=1 tr=0 a=AppmJ/7ZOOFWL/q6u6u93g==:117 a=AppmJ/7ZOOFWL/q6u6u93g==:17 a=ayC55rCoAAAA:8 a=fNEgcOh0sVsA:10 a=o_R75loqY_IA:10 a=9i_RQKNPAAAA:8 a=LlYXJ7qtg0bYfvZtK84A:9 X-Cloudmark-Score: 0 X-detected-operating-system: by eggs.gnu.org: BaiduSpider X-Received-From: 107.14.73.225 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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 Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175567 Archived-At: Stefan Monnier writes: >> I agree it would be nice to be able to do that in a single root, but I >> suspect it is not possible in general, because there could be >> conflicting requirements; you'd end up with full copies of /* for each >> version anyway. > > I can't see why. I already have emacs19, emacs20, emacs21, emacs22, > emacs23, and emacs24 installed at the same time, so I can't see what new > problem would be introduced by refining this to the minor > version number. For specific packages with similar dependencies, that works. But suppose emacs19 depended on gtk1, and emacs20 on gtk2, emacs21 on gtk3, etc. And each gtkn had different, changing dependencies as well. You'd end up with unique copies of the entire dependency tree for each emacsn. In practice, since the dependencies are more stable than that, the total tree would be much smaller than the full copy for each that you get from the chroot approach. I suspect, as has been said here before, the main problem is the maintainer effort required to make installing minor versions in parallel possible; renaming files to include version numbers in every file name/path for each release. dpkg doesn't do that for you. If you tried to upgrade dpkg to do the file/path versioning automatically, it would have to take a very conservative approach, leading the full copy as above. That might work, but I suspect there would be problems; for example, if C headers have "#include foo;"; dpkg could not possibly be expected to handle that by editing the file. Any hardcoded version in a build script or source file would fail. -- -- Stephe