emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Integrating package.el


From: Ted Zlatanov
Subject: Re: Integrating package.el
Date: Tue, 05 Jan 2010 14:18:27 -0600
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.90 (gnu/linux)

On Tue, 05 Jan 2010 11:47:46 -0500 Stefan Monnier <address@hidden> wrote: 

>> The "package file" (analogous to a RPM/DEB package fike) should contain
>> the real, final version of all the files.  The package repository may
>> accumulate metadata about all the package files it contains, but I
>> should be able to copy a single package file to another system and
>> install it.  As a sysadmin I don't want package files to be
>> indeterminate.  For instance, how can I set up a local mirror if some of
>> the files inside some of the package files are possibly remote?  There's
>> all the other security risks I listed in my previous note, too,
>> concerning remote network access.

>> This is a huge sysadmin problem with Perl for instance, where the
>> liberal packaging standard and complicated build process make it hard to
>> synchronize packages across multiple installations.  I've suffered
>> through that many times and hope it doesn't recur with Emacs packages.
>> Some OS integration (DEB, RPM, MacOS X, etc.) would be useful, at least
>> as a possibility.

SM> OK, I'm not sure whether we're talking about the same things.

I digressed too much, sorry.

SM> The way I see it, there will be the following elements:

SM> - a (set of) Bzr repository holding the package sources.

Yes, with initial members "FSF supported," "FSF unsupported" (both
hosted inside the Emacs Bzr repo) and "ELPA" (hosted externally, may not
be a Bazaar repository at all).  This is the storage backend.  The "FSF
supported" storage may be the lisp/ directory inside Emacs, for
instance.

SM> - a tool that will build tarballs from those sources.

Yes, including the necessary package metadata inside the file.  This
tool will probably come from ELPA.

SM> - an area where those tarballs are stored, along with some metadata
SM>   (think Debian repository).

All of this is MHO: there should be three areas to parallel the storage
backends above.  They may be stored inside the backend or externally.
The package repositories should be identified by a single URL; the ones
that come with Emacs should point to a secure Savannah URL.  That may
address RMS' concerns about loading software over the network.  Jonas'
emacsmirror.org would be a fourth package repository, probably not
enabled by default but easy to enable.

SM> - a tool that can scan such repositories and downlooad packages from
SM>   them, obeying dependencies (think APT).

This is package.el IIUC.

SM> - a tool that can install/activate/uninstall a given package, ... (think
SM>   DPKG).  This last one is what I tried to write when I wrote install.el
SM>   many moons ago.

This is also package.el IIUC.

Ted





reply via email to

[Prev in Thread] Current Thread [Next in Thread]