Re: Integrating package.el

[Tom Tromey]

>>>>> "Ted" == Ted Zlatanov <address@hidden> writes:

Tom> It also needs to be changed to be able to manage multiple install
Tom> locations, if it is to be used to manage site-lisp.

Ted> Good point, but do you mean multiple search locations for existing
Ted> installs?  I would expect a single install location, otherwise it gets
Ted> complicated...

Basically we need to handle 3 install locations: the Emacs install tree,
the global site-lisp, and the user's install location.

These only need to be handled during the activation step.  When the user
installs a new package, it should always go to his personal install
location.

Right now package.el handles the Emacs install tree in a hacky way and
ignores site-lisp entirely.

Ted> This has been a very
Ted> common complaint about Gnus.  Installing it is the easy part, since it
Ted> comes with Emacs.  Can package.el support that?  I can't tell if this is
Ted> the "activate" or the "load" stage (are they states or state
Ted> transitions?  English can be so ambiguous...) or something new; also it
Ted> seems like this is something external to Gnus, a function of the ELPA
Ted> wrapper (although it may be bundled within Gnus) rather than something
Ted> Gnus will always run for new users.  This is the major question I have
Ted> before I propose this packaging on the Gnus mailing list.

This would be a new thing.

I agree with the other posters who recommend that this be done in Gnus,
not as something related to package.el.

Ted> I also want to know if you and Phil want to make Gnus your first
Ted> Emacs-hosted package, or if there's going to be a ELPA clone of Gnus.

FWIW, ELPA already includes some packages that are also included in
Emacs.  I maintain the necessary metadata for this by hand (and, I'm
afraid, not very well at the moment due to lack of time -- I think I am
missing some updates).

Ted> I'd actually like both: the Emacs-hosted version is "Emacs-supported
Ted> Gnus" while the ELPA versions are "bleeding-edge Gnus from CVS" and
Ted> "latest Gnus release."  The last one is usually but not always
Ted> synchronized with the Emacs release; I'll need to ask the other Gnus
Ted> developers what they think.  At least two Gnus versions in package.el
Ted> make sense in any case.

package.el doesn't support this at the moment.

Thanks for bringing this up, though.  I think it is pretty important to
flush out all these use cases.

I can think of a couple solutions to this problem.

One would be to somehow let users select different package versions.
Normally, though, users don't actually want this -- when a new version
is released, ordinarily all the old ones are obsolete.

Another solution would be to have two repositories, one for stable
packages and one for experimental.  This wouldn't require any changes to
package.el.

Tom