Re: feature/integrated-elpa 4f6df43 15/23: README added

[Achim Gratz]

Phillip Lord writes:
> And this could only work for org.el *because* org is in it's own
> directory with its own autoloads file. For seq.el, for instance, it will
> not work.

No, some autoloads still get collected into the top-level autoloads
file.  The same two-layer mechanism is used by calc.el, IIRC.

> IIUC, in fact it's the org-mode folks actually view this as a
> significant *disadvantage* to having org-mode in core. It's only because
> this is the only way to get it into the tarball that they do it. Achim,
> do I have this right?

Please talk to the current Org maintainers about this, I was unable to
spend much time on Org during the last year or so.  In any case, I don't
think this should be viewed as an issue with Org, that's certain to rub
someone the wrong way.

My personal biew is that anything that shows up as a "built-in package"
should behave just like it had been installed by package.el from the POV
of a user.  So, a user should be able to cleanly deactivate or upgrade
each such package via package.el.

> There are a few other things that package.el does, which it would be
> shame to loose. It checks dependencies for instance. So, say, I
> installed assess.el into Emacs core using package.el as I suggest, and
> it requires a newer version of seq.el than is available, package.el will
> bitch about this very early.

Paackage.el has it's own limitations which unfortunately are also
highlighted by Org.  Some of the files that go into ELPA Org are
actually generated by an upstream makefile so that the tarball that ELPA
distributes can be successfully installed within those limitations.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds