Re: CVS is the `released version'

[Tom Tromey]

A few belated responses to this thread, all in one message.
I'll try to lay out some of my thinking behind package.el.

Ken> (1) we are talking about enabling package developers and users to update
Ken>     the packages they use incrementally within a major emacs release,
Ken> (2) without burdening emacs maintainers with change management chaos,
Ken>     and

package.el came from a few ideas.  The obvious one was to replace the
ELL/Wiki/Ohio State Archive with something more machine-friendly (and
thus simpler to make user-friendly).  However I also wanted to be able
to install a package (e.g., ERC) that was later pulled into Emacs;
upgrade Emacs; and have my old, personal ERC install not be used any
more.  I've run into this situation any number of times in the past,
and with the long Emacs release cycle and the many packages that exist
now, it seemed a bit more important.

This second idea basically works.  It would work better with a bit of
assistance from Emacs -- say a way to auto-compute the default value
for `package-alist' at build time.

Ken> (3) without reducing the incentive for package developers to assign
Ken>     copyright to the fsf.

I don't know how to accomplish this to RMS' satisfaction.  But perhaps
some of the infrastructure from package.el can still end up in Emacs.

Ken> (2) is the tricky bit.  the situation would be simplest if the
Ken> update system is contrived to only allow the entire collection of
Ken> packages to be updated at as a whole.

There are some theoretical problems here but I was planning to address
them from the "active maintenance" point of view -- i.e., the ELPA
maintainers would simply ensure, somehow, that the archive is
internally consistent.  This is related to...

Lennart> I think this touches the most important point of a package
Lennart> system. There must be something that can assure that the
Lennart> package to download fits on the users system.

I didn't want to try to deal with this in its full hairiness, but
package.el at least solves part of the problem, namely by letting
packages require minimum versions of other packages (including the
special package "emacs").

Lennart> So please, do not add a package system that can only handle
Lennart> single files and not their interdependencies.

package.el handles both `single' and `tar' packages, and either type
can have dependencies.  Which is related to...

Dhruva> Is it feasible/practical to have a keyword in the comment area
Dhruva> of the file "providing" the package with list of depedencies
Dhruva> and their locations?

package.el doesn't deal with locations -- it assumes a single
location.  I am not a fan of the location-per-package approach,
because I think a lesson from ELL is that locations often die.
However, package.el does handle requirements, even for `single'
packages, by defining a new "Package-Requires" header comment.  E.g.,
a .el file that requires Emacs 22 could have:

    ;; Package-Requires: ((emacs "22.0"))

Offhand I don't think anything currently in ELPA does this.  But then,
I haven't put much effort into trying to upload the bigger things out
there.

Tom