From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Eilert Newsgroups: gmane.emacs.devel Subject: Re: Emacs Package Management Date: Wed, 16 Sep 2009 19:36:29 -0300 Message-ID: <485b0c380909161536t331a71fdg1c45150c418b72b2@mail.gmail.com> References: <485b0c380808011427n4d3144eey3f8daf3abac83bf4@mail.gmail.com> <87ej589vku.fsf@hagelb.org> <485b0c380808050609y56042595l42a5bb05b34458f0@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0015173ff15ec56b420473b987ed X-Trace: ger.gmane.org 1253140616 12418 80.91.229.12 (16 Sep 2009 22:36:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Sep 2009 22:36:56 +0000 (UTC) Cc: tromey@redhat.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, phil@hagelb.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 17 00:36:48 2009 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 1Mo37I-0004On-FA for ged-emacs-devel@m.gmane.org; Thu, 17 Sep 2009 00:36:48 +0200 Original-Received: from localhost ([127.0.0.1]:33136 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mo37H-00066x-TK for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2009 18:36:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mo37A-00062Q-QY for emacs-devel@gnu.org; Wed, 16 Sep 2009 18:36:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mo376-0005vX-Ag for emacs-devel@gnu.org; Wed, 16 Sep 2009 18:36:40 -0400 Original-Received: from [199.232.76.173] (port=50995 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mo376-0005vN-2g for emacs-devel@gnu.org; Wed, 16 Sep 2009 18:36:36 -0400 Original-Received: from mail-fx0-f226.google.com ([209.85.220.226]:42305) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mo373-0002yh-0v; Wed, 16 Sep 2009 18:36:33 -0400 Original-Received: by fxm26 with SMTP id 26so4060683fxm.42 for ; Wed, 16 Sep 2009 15:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6BIYAVPY2b5UaPpT8JvlWZ0wrXOusB9s24/qdLP6GJA=; b=GDv3lxUiMYbIsbHnNBhONgg3Mpc5ohxJCM7vdnw5CflszN9FEsEQr9FF1N8QAlIzXv W5Uz6oWDn6hiGrLq7AzFGEy94w5/NvNbu3zw7M5iGcGhd5piWmUG6UsRUh9O5FlgHTqP GPwTNzd/sLvKITKw7wT5DhsVZohIYvu6a3YRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gSC84o7RlL3XqWot8g96Z88vHBZiOhOoCF49dob7rzLBHOuG78POLu1pMe1oiOeqJX ksASVxWJo4rpk1Rrf6v7ULbY7vJ3X1DBgsigDUqQpPHYDPQzCooMPqjr1yknBjD4S891 sRr5JwBndG2TFRywjznDf9iBMC2JrDBlEIZTs= Original-Received: by 10.223.2.69 with SMTP id 5mr3219434fai.88.1253140590848; Wed, 16 Sep 2009 15:36:30 -0700 (PDT) In-Reply-To: X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:115399 Archived-At: --0015173ff15ec56b420473b987ed Content-Type: text/plain; charset=UTF-8 On Wed, Aug 6, 2008 at 12:35 AM, Richard M. Stallman wrote: > In the context of package management, who's going to enforce those > package > restrictions? Should packages be approved manually before being added to > whatever repository we devise? > > We could treat them the same way as if they were included in the > usual Emacs distribution, in effect spitting that distribution into parts. > To sum it up: there *is* interest in a packaging feature, and the issues seem to be mostly in the area of copyright assignment. If that's correct, this is good. ELPA is a nice starting point. But I think it is disproportionally easy to download packages, as opposed to submitting them. For single files, I would very much like to have a M-x submit-package, and have it do anything required to upload it, adding licenses and so on. I don't mind if packages have to be approved for inclusion in official repositories, but it should be easy to upload them. For FSF packages, it could sign them with the user's key. Dependencies management is also nice, but we'd have to have a way to identify packages. And, most importantly, failing packages should not interrupt emacs startup. I've implemented a simple system(for my own use) where it creates a buffer with package load status. Failing packages are skipped, but obviously there is no way to undo side-effects. --Stephen programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters. --0015173ff15ec56b420473b987ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Aug 6, 2008 at 12:3= 5 AM, Richard M. Stallman <rms@gnu.org> wrote:
=C2=A0 =C2=A0In the context of package management, who's going to= enforce those package
=C2=A0 =C2=A0restrictions? Should packages be approved manually before bei= ng added to
=C2=A0 =C2=A0whatever repository we devise?

We could treat them the same way as if they were included in the
usual Emacs distribution, in effect spitting that distribution into parts.<= br>

To sum it up: there *is* interest in a packaging fea= ture, and the issues seem to be mostly in the area of copyright assignment.= If that's correct, this is good.

ELPA is a nice starting point. But I think it is disproportionally easy to = download packages, as opposed to submitting them. For single files, I would= very much like to have a M-x submit-package, and have it do anything requi= red to upload it, adding licenses and so on. I don't mind if packages h= ave to be approved for inclusion in official repositories, but it should be= easy to upload them. For FSF packages, it could sign them with the user= 9;s key.

Dependencies management is also= nice, but we'd have to have a way to identify packages.

And, most importantly, failing packages= should not interrupt emacs startup. I've implemented a simple system(f= or my own use) where it creates a buffer with package load status. Failing = packages are skipped, but obviously there is no way to undo side-effects.

--Stephen

programmer, n:
A red eyed, mumbl= ing mammal capable of conversing with inanimate monsters.

--0015173ff15ec56b420473b987ed--