Re: Integrating package.el

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 05 Jan 2010 10:06:56 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>> Tom Tromey <tromey@redhat.com> writes:
>>> I've also got a quick prototype of a DVCS-centric archive management
>>> tool (for gathering packages from library authors and publishing them)
>>> that I will post soon once I've fleshed it out a bit more.
>> This sounds good to me. I believe that ELPA should not hold the files
>> but rather have pointers to them. Otherwise the turnaround time will
>> be longer for changes made to the files.

SM> The default repositor(y|ies) will want to be under FSF control (not just
SM> the copyright, but we also want to have a copy of the files, etc...) so
SM> we can assume that the FSF will usually also hold the "master
SM> repository" for those packages.

SM> I.e. we probably don't want to only hold pointers to files.  Tho of
SM> course, such an indirection might still be useful somewhere.

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.

Ted