[Top][All Lists]

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

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

From: Phillip Lord
Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added
Date: Tue, 18 Oct 2016 11:54:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Achim Gratz <address@hidden> writes:

> 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.

Most of them are in loaddefs. Quite a few "packages" have their own.

>> 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.

Apologies if it read like this; I don't think this is a problem with
org, I think it's a problem with Emacs.

> 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.

Do tell. Which files are generated?

Using package.el in core would force us to fix these things, I think,
which is a good thing!


reply via email to

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