From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: CVS is the `released version' Date: Mon, 14 May 2007 13:16:17 -0600 Message-ID: References: <2cd46e7f0705101124r72000f78xdf05d18ca815ca57@mail.gmail.com> <17991.47259.210100.801472@localhost.localdomain> <864pmfzz3c.fsf@lola.quinscape.zz> <17992.31731.577467.566308@localhost.localdomain> Reply-To: tromey@redhat.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1179171310 22887 80.91.229.12 (14 May 2007 19:35:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 14 May 2007 19:35:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 14 21:35:08 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HngK1-0000Fc-VF for ged-emacs-devel@m.gmane.org; Mon, 14 May 2007 21:35:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HngRo-0001pP-Ld for ged-emacs-devel@m.gmane.org; Mon, 14 May 2007 15:43:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HngRl-0001ow-HP for emacs-devel@gnu.org; Mon, 14 May 2007 15:43:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HngRk-0001oK-VC for emacs-devel@gnu.org; Mon, 14 May 2007 15:43:05 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HngRk-0001o5-SE for emacs-devel@gnu.org; Mon, 14 May 2007 15:43:04 -0400 Original-Received: from mx1.redhat.com ([66.187.233.31]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HngJw-0007Jh-MW; Mon, 14 May 2007 15:35:00 -0400 Original-Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l4EJYxFj021752; Mon, 14 May 2007 15:34:59 -0400 Original-Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l4EJYxto005451; Mon, 14 May 2007 15:34:59 -0400 Original-Received: from opsy.redhat.com (ton.toronto.redhat.com [172.16.14.15]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l4EJYwIC006103; Mon, 14 May 2007 15:34:58 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 88E6F37838B; Mon, 14 May 2007 13:16:17 -0600 (MDT) X-Attribution: Tom In-Reply-To: (Eli Zaretskii's message of "Mon\, 14 May 2007 22\:03\:40 +0300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (gnu/linux) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:71063 Archived-At: >>>>> "Eli" == Eli Zaretskii writes: Eli> There are problems with this that no package system can ever solve: a Eli> package that is released asynchronously from Emacs runs a high risk to Eli> become broken by changes in Emacs. Packages that are released Eli> together with Emacs are generally coherent with the Emacs core, by Eli> contrast. Yes, that is true for some subset of packages. But, it is by no means universally true. And, package.el makes an attempt to solve a related problem experienced by users (me, at the very least): when an external package is included in Emacs, package.el knows to disable the privately installed copy in favor of the newer version included in Emacs. Eli> As long as this is a real problem (and I personally don't see how it Eli> can be solved, given the high rate of changes in core code), this Eli> ``biggest benefit'' is actually a myth, IMHO. I think you are drawing an overly general conclusion here. A package manager does not have to be perfect and solve every conceivable case in order to be better than the status quo. It merely has to provide some tangible benefit to users. Not solving every case does not entirely eliminate the benefits of this application. And, anyway, when a new Emacs is released, package maintainers can update their packages. Tom