* Re: Future role of ELPA
2016-02-16 8:05 ` Future role of ELPA (was: [ELPA] tramp-theme.el) Stefan Reichör
@ 2016-02-16 8:25 ` Christian Kruse
2016-02-16 8:46 ` Michael Albinus
2016-02-16 8:57 ` Oleh Krehel
` (3 subsequent siblings)
4 siblings, 1 reply; 35+ messages in thread
From: Christian Kruse @ 2016-02-16 8:25 UTC (permalink / raw)
To: Stefan Reichör; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]
Hi,
I am an Emacs user as well, and I so much disagree with you.
Stefan Reichör <stefan@xsteve.at> writes:
> As I user I am not happy with that direction.
> Let me try to explain it.
> I use Emacs since about 20 years. I use it daily and it is my primary
> interface to computer related tasks. For sure I can adopt to what ever
> direction emacs goes.
17 year here, since ‘99. I use Emacs for nearly everything as well.
> I use a hand crafted .emacs and I am used to install emacs packes
> manually to a site-lisp folders.
Me, too, and I hated it. It was *SO* much work to keep track of
everything I installed this way; for bigger packages I even had to
change the load path to get it installed properly.
Nowadays I just hit „install“ - done.
> With GNU ELPA I have to install the package first and get rid of it if I
> don't like it.
That’s easier now as well. Just `rm -rf` the sub-directory in the elpa
directory and be done with it. Try to remove e.g. org-mode from the
Emacs distribution.
> My main concern with GNU ELPA is that I have to install a lot of extra
> packages manually using the package manager. When they are built-in they
> are just there.
That’s exactly what I like about ELPA. I decide what I’d like to have
installed, and not some maintainer. For example I would never install
tramp, this bugged piece of software caused me so much trouble (for
example, `/dev/null` gets overwritten everytime I use tramp and I have
to do a `mknod` everytime to re-create it).
Moving more things to ELPA means more control for me, and it also means
faster bugfixes for packages I use. I don’t have to wait for a new Emacs
release to get a bugfix for e.g. org-mode, but I can install a new
version as soon as it has been released just by hitting enter on the
install button.
I totally like the way of moving things to ELPA.
Best regards,
--
Christian Kruse
https://wwwtech.de/about
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: Future role of ELPA
2016-02-16 8:25 ` Future role of ELPA Christian Kruse
@ 2016-02-16 8:46 ` Michael Albinus
2016-02-16 9:02 ` Christian Kruse
2016-02-16 9:18 ` Przemysław Wojnowski
0 siblings, 2 replies; 35+ messages in thread
From: Michael Albinus @ 2016-02-16 8:46 UTC (permalink / raw)
To: Christian Kruse; +Cc: Stefan Reichör, emacs-devel
Christian Kruse <cjk@defunct.ch> writes:
> Hi,
Hi Christian,
> That’s exactly what I like about ELPA. I decide what I’d like to have
> installed, and not some maintainer. For example I would never install
> tramp, this bugged piece of software caused me so much trouble (for
> example, `/dev/null` gets overwritten everytime I use tramp and I have
> to do a `mknod` everytime to re-create it).
Honour to whom honour is due: its'a a bash bug. See Bug#19731.
And I agree with you: with Tramp being also in ELPA, you would have get
a bug fix already, instead of waiting for Emacs 25.1.
> Best regards,
Best regards, Michael.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Future role of ELPA
2016-02-16 8:46 ` Michael Albinus
@ 2016-02-16 9:02 ` Christian Kruse
2016-02-16 9:15 ` Michael Albinus
2016-02-16 9:18 ` Przemysław Wojnowski
1 sibling, 1 reply; 35+ messages in thread
From: Christian Kruse @ 2016-02-16 9:02 UTC (permalink / raw)
To: Michael Albinus; +Cc: Stefan Reichör, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]
Hi Michael,
Michael Albinus <michael.albinus@gmx.de> writes:
>> That’s exactly what I like about ELPA. I decide what I’d like to have
>> installed, and not some maintainer. For example I would never install
>> tramp, this bugged piece of software caused me so much trouble (for
>> example, `/dev/null` gets overwritten everytime I use tramp and I have
>> to do a `mknod` everytime to re-create it).
>
> Honour to whom honour is due: its'a a bash bug. See Bug#19731.
I don’t even use Bash but ZSH, sorry ;-)
I didn’t want to be offensive, sorry about that. I noticed that I was
offensive now, after I read the cite. I’m sorry.
Best regards,
--
Christian Kruse
https://wwwtech.de/about
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Future role of ELPA
2016-02-16 9:02 ` Christian Kruse
@ 2016-02-16 9:15 ` Michael Albinus
2016-02-16 10:16 ` Christian Kruse
0 siblings, 1 reply; 35+ messages in thread
From: Michael Albinus @ 2016-02-16 9:15 UTC (permalink / raw)
To: Christian Kruse; +Cc: Stefan Reichör, emacs-devel
Christian Kruse <cjk@defunct.ch> writes:
> Hi Michael,
Hi Christian,
>> Honour to whom honour is due: its'a a bash bug. See Bug#19731.
>
> I don’t even use Bash but ZSH, sorry ;-)
It's about the shell on the remote host, which is invoked via /bin/sh.
Anyway, if you want to get rid of this bug, use the recent Tramp release
2.2.13 (not available via ELPA yet). Or the pretest version of Emacs 25.1.
> Best regards,
Best regards, Michael.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Future role of ELPA
2016-02-16 8:46 ` Michael Albinus
2016-02-16 9:02 ` Christian Kruse
@ 2016-02-16 9:18 ` Przemysław Wojnowski
1 sibling, 0 replies; 35+ messages in thread
From: Przemysław Wojnowski @ 2016-02-16 9:18 UTC (permalink / raw)
To: Michael Albinus; +Cc: emacs-devel
W dniu 2016-02-16 09:46, Michael Albinus napisał(a):
[...]
> And I agree with you: with Tramp being also in ELPA, you would have get
> a bug fix already, instead of waiting for Emacs 25.1.
This is the main reason I would like to see all packages in a repository
instead of bundled with Emacs. This would make Emacs smaller, easier to
maintain, release and value (features, new packages, bugfixes, etc.)
would be faster delivered to users.
Is there any reason why, let's say, cc-mode cannot be in ELPA? Certainly
not.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Future role of ELPA
2016-02-16 8:05 ` Future role of ELPA (was: [ELPA] tramp-theme.el) Stefan Reichör
2016-02-16 8:25 ` Future role of ELPA Christian Kruse
@ 2016-02-16 8:57 ` Oleh Krehel
2016-02-16 15:26 ` Future role of ELPA (was: [ELPA] tramp-theme.el) Drew Adams
` (2 subsequent siblings)
4 siblings, 0 replies; 35+ messages in thread
From: Oleh Krehel @ 2016-02-16 8:57 UTC (permalink / raw)
To: Stefan Reichör; +Cc: emacs-devel
Stefan Reichör <stefan@xsteve.at> writes:
> I am reading the emacs devel list. And I know that this is the direction
> that is desired by most/all developers.
> Consider a simple customization like tramp-theme. When everything is in
> stock emacs: I just can change the value of a customization variable and
> see what happens.
>
> With GNU ELPA I have to install the package first and get rid of it if I
> don't like it.
>
> My main concern with GNU ELPA is that I have to install a lot of extra
> packages manually using the package manager. When they are built-in they
> are just there.
>
> So I hope that many useful features will still be shipped with Emacs as
> integrated packages.
This can easily be made configurable. There's nothing that prevents us
from injecting selected ELPA packages (like gnus or tramp) into the main
lisp/ directory during Emacs installation. Then, instead of
`package-install', a plain `require' would work.
My impression was that this is the way the "bundled ELPA" packages will
work. The slightly tricky part is modifying `package-initialize' so that
any package in GELPA would supersede the bundled version, since it's
newer. But it's just a matter of calling it once and sorting
`load-path'.
Oleh
^ permalink raw reply [flat|nested] 35+ messages in thread* RE: Future role of ELPA (was: [ELPA] tramp-theme.el)
2016-02-16 8:05 ` Future role of ELPA (was: [ELPA] tramp-theme.el) Stefan Reichör
2016-02-16 8:25 ` Future role of ELPA Christian Kruse
2016-02-16 8:57 ` Oleh Krehel
@ 2016-02-16 15:26 ` Drew Adams
2016-02-16 17:52 ` Future role of ELPA John Wiegley
2016-02-17 18:42 ` Phillip Lord
4 siblings, 0 replies; 35+ messages in thread
From: Drew Adams @ 2016-02-16 15:26 UTC (permalink / raw)
To: Stefan Reichör, emacs-devel
> >> As a user I really don't like that a lot of functionality is now moved to
> >> ELPA. When I install a new emacs, I have to re-install also all needed
> >> packages from ELPA.
A reasonable critique, I think.
> >> It would be so much easier when all the batteries in emacs are still
> >> included.
> >
> > The future plan is to move even more things into ELPA. However, parts of
> > ELPA will be included in future Emacs tarballs, so your batteries will
> > actually be there in that future.
> >
> > So, rather than asking whether things can move back into Emacs, the better
> > question is: how should we proceed with our plan to deeply integrate ELPA,
> > so questions like this are resolved in passing. We've had some progress in
> > this direction, but there are still a few matters of process to resolve.
Exactly. I'm glad that this user (Stefan) posed the question and made known
his use case. It should be taken into account ("resolved in passing").
> I am reading the emacs devel list. And I know that this is the direction
> that is desired by most/all developers.
>
> As I user I am not happy with that direction.
> Let me try to explain it.
> I use Emacs since about 20 years. I use it daily and it is my primary
> interface to computer related tasks. For sure I can adopt to what ever
> direction emacs goes.
>
> I use a hand crafted .emacs and I am used to install emacs packes
> manually to a site-lisp folders.
>
> Consider a simple customization like tramp-theme. When everything is in
> stock emacs: I just can change the value of a customization variable and
> see what happens.
>
> With GNU ELPA I have to install the package first and get rid of it if I
> don't like it.
>
> My main concern with GNU ELPA is that I have to install a lot of extra
> packages manually using the package manager. When they are built-in they
> are just there.
Indeed.
> So I hope that many useful features will still be shipped with Emacs as
> integrated packages.
I agree with you. But I also agree that it is good to modularize the
Emacs code, e.g. by moving some of it to GNU ELPA. That can help both
Emacs development and the use cases of some users.
I agree with you that a user should be able to ask Emacs about something
(e.g., a command) that has traditionally been provided with the Emacs
distribution, without having to use the package system to add it.
In a way, perhaps what is needed is a "super autoload" facility, that
is, a more sophisticated way of making use of the package system,
so that the same behavior as before a breakup into separate packages
is still available seamlessly, even if under the covers packages are
brought into play.
The key here is "under the covers": A user should not _need_ to do
anything or even to be aware that packages are being jockeyed into
place automatically to accommodate an inquiry or an on-demand use
of a feature.
A user should not be required to (consciously, manually) use the
package system at all, to interact usefully with Emacs. A user
should be able to have everything that s?he had from Emacs
previously on disk, locally, without jumping through any hoops.
There should be no need to connect to the Internet to work with
Emacs, at least regarding the large set of commands, options, etc.
that has traditionally been distributed with Emacs.
IOW, it should be possible for a user to use Emacs without the
package system, just as easily as before. Adding the package
system should be only a plus, not a plus and a minus. Users should
be able to interact with Emacs in different ways, and not be obliged
to get only a tiny core by default and then have to install the
pieces they feel are missing.
At the same time, it would be good if the Emacs code were composable
from libraries in a repository such as GNU ELPA. How these two needs
can best be composed I don't know. But I don't think we should
be sacrificing user access to what used to be the Emacs code base on
the alter of the package system.
What is convenient for Emacs development and for some users some of
the time should not trump the ability of other users (or the same
users at other times) to interact with Emacs as they would have
before the package system. If you need to activate a package to get
information about `forward-sexp' or whatever, then we have lost something.
That users _can_ choose not to "install" Tramp or whatever is a
good thing, no doubt. But it is not necessarily a good thing that
users should have to manually "install" Tramp or whatever, just to
be able to talk to Emacs about it or even to make use of it.
All this is a way of saying that we might need to think some more
about how Emacs and Emacs Dev make use of the package system, a
system that, on its own, is a good thing. It should not become
a sledgehammer that makes everything in Emacs look like a nail.
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: Future role of ELPA
2016-02-16 8:05 ` Future role of ELPA (was: [ELPA] tramp-theme.el) Stefan Reichör
` (2 preceding siblings ...)
2016-02-16 15:26 ` Future role of ELPA (was: [ELPA] tramp-theme.el) Drew Adams
@ 2016-02-16 17:52 ` John Wiegley
2016-02-16 18:51 ` Stefan Reichör
2016-02-17 18:42 ` Phillip Lord
4 siblings, 1 reply; 35+ messages in thread
From: John Wiegley @ 2016-02-16 17:52 UTC (permalink / raw)
To: stefan; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]
>>>>> Stefan Reichör <stefan@xsteve.at> writes:
> My main concern with GNU ELPA is that I have to install a lot of extra
> packages manually using the package manager. When they are built-in they are
> just there.
Hi Stefan,
Have no fear: I never use package.el myself, since I also prefer to curate
hand-installed packages.
So what does moving to ELPA mean?
There would be a large set of ELPA packages (maybe all of them to start) that
will appear in the tarball when you download and install Emacs. This means --
I think -- that they should populate the site-wide site-lisp directory, and
appear to users as if they had come "with Emacs"; that is, either autoloading
or a manual `require' statement to make the functionality available.
There are a few advantages to this:
1. After installation of Emacs, package.el can be used to upgrade select
packages independent of our release cycle.
2. Developers can get packages into the Emacs distribution without having to
justification inclusion in core.
3. Code "in development" is free to appear in ELPA, whereas we tend to frown
on APIs that will change often in Emacs itself.
The bottom line is that, as a user, you shouldn't notice much difference after
installation, but you'll gain the benefit of optionally performing frequent
updates of ELPA packages. As an Emacs developer, the advantage is that it
simplifies the Emacs Git repository, and makes it easier for external authors
to focus on maintaining their packages within ELPA.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: Future role of ELPA
2016-02-16 17:52 ` Future role of ELPA John Wiegley
@ 2016-02-16 18:51 ` Stefan Reichör
2016-02-16 19:26 ` Michael Albinus
` (3 more replies)
0 siblings, 4 replies; 35+ messages in thread
From: Stefan Reichör @ 2016-02-16 18:51 UTC (permalink / raw)
To: emacs-devel
John Wiegley <jwiegley@gmail.com> writes:
>>>>>> Stefan Reichör <stefan@xsteve.at> writes:
>
>> My main concern with GNU ELPA is that I have to install a lot of extra
>> packages manually using the package manager. When they are built-in they are
>> just there.
>
> Hi Stefan,
>
> Have no fear: I never use package.el myself, since I also prefer to curate
> hand-installed packages.
>
> So what does moving to ELPA mean?
>
> There would be a large set of ELPA packages (maybe all of them to start) that
> will appear in the tarball when you download and install Emacs. This means --
> I think -- that they should populate the site-wide site-lisp directory, and
> appear to users as if they had come "with Emacs"; that is, either autoloading
> or a manual `require' statement to make the functionality available.
>
> There are a few advantages to this:
>
> 1. After installation of Emacs, package.el can be used to upgrade select
> packages independent of our release cycle.
>
> 2. Developers can get packages into the Emacs distribution without having to
> justification inclusion in core.
>
> 3. Code "in development" is free to appear in ELPA, whereas we tend to frown
> on APIs that will change often in Emacs itself.
>
> The bottom line is that, as a user, you shouldn't notice much difference after
> installation, but you'll gain the benefit of optionally performing frequent
> updates of ELPA packages. As an Emacs developer, the advantage is that it
> simplifies the Emacs Git repository, and makes it easier for external authors
> to focus on maintaining their packages within ELPA.
I see.
A simpler way to upgrade selected packages is good thing.
Some things that should be considered for the package system:
1. Not only emacs provides a package manager. Linux distributions also
provide some packages. Not sure if this is a good idea.
The same situation is e.g. for python. You can use pip to install
packages. And there are python packages provided by distributions.
Some people prefer OS packages, some prefer the native package manager.
Not sure what to do about this situation.
2. The packages should not be too fine grained. It is not very useful to
split e.g. tramp in 20 sub-packages for example.
I don't want to be overwhelmed by 100s or 1000s of packages.
Perhaps we could have some kind of installation counter to find
useful packages. Or even some kind of voting system.
Stefan.
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: Future role of ELPA
2016-02-16 18:51 ` Stefan Reichör
@ 2016-02-16 19:26 ` Michael Albinus
2016-02-16 19:45 ` John Wiegley
` (2 subsequent siblings)
3 siblings, 0 replies; 35+ messages in thread
From: Michael Albinus @ 2016-02-16 19:26 UTC (permalink / raw)
To: Stefan Reichör; +Cc: emacs-devel
Stefan Reichör <stefan@xsteve.at> writes:
> 2. The packages should not be too fine grained. It is not very useful to
> split e.g. tramp in 20 sub-packages for example.
Don't fear this, I'm not going this way. tramp-theme.el has just stolen
the name from Tramp because it is a brand. It does not depend on Tramp
itself, and it cooperates with any other file name handler which offers
file-remote-p functionality.
> Stefan.
Best regards, Michael.
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: Future role of ELPA
2016-02-16 18:51 ` Stefan Reichör
2016-02-16 19:26 ` Michael Albinus
@ 2016-02-16 19:45 ` John Wiegley
2016-02-17 15:59 ` Richard Stallman
2016-02-21 2:18 ` Stefan Monnier
3 siblings, 0 replies; 35+ messages in thread
From: John Wiegley @ 2016-02-16 19:45 UTC (permalink / raw)
To: Stefan Reichör; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]
>>>>> Stefan Reichör <stefan@xsteve.at> writes:
> 1. Not only emacs provides a package manager. Linux distributions also
> provide some packages. Not sure if this is a good idea. The same situation
> is e.g. for python. You can use pip to install packages. And there are
> python packages provided by distributions. Some people prefer OS packages,
> some prefer the native package manager. Not sure what to do about this
> situation.
I afraid that solving this is out of scope for us.
> 2. The packages should not be too fine grained. It is not very useful to
> split e.g. tramp in 20 sub-packages for example. I don't want to be
> overwhelmed by 100s or 1000s of packages. Perhaps we could have some kind of
> installation counter to find useful packages. Or even some kind of voting
> system.
Certainly, this is a matter of wisdom on the part of package submitters.
Egregious exceptions will need to be considered on a case-by-case basis.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Future role of ELPA
2016-02-16 18:51 ` Stefan Reichör
2016-02-16 19:26 ` Michael Albinus
2016-02-16 19:45 ` John Wiegley
@ 2016-02-17 15:59 ` Richard Stallman
2016-02-21 2:18 ` Stefan Monnier
3 siblings, 0 replies; 35+ messages in thread
From: Richard Stallman @ 2016-02-17 15:59 UTC (permalink / raw)
To: Stefan Reichör; +Cc: emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 1. Not only emacs provides a package manager. Linux distributions also
> provide some packages.
You're talking about versions of the GNU system.
Please don't call them "Linux distributions"!
That gives the credit for our system
to someone else, and not at all to us.
It treats us very badly.
See http://gnu.org/gnu/linux-and-gnu.html and
http://gnu.org/gnu/gnu-linux-faq.html, plus the history in
http://gnu.org/gnu/the-gnu-project.html.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Future role of ELPA
2016-02-16 18:51 ` Stefan Reichör
` (2 preceding siblings ...)
2016-02-17 15:59 ` Richard Stallman
@ 2016-02-21 2:18 ` Stefan Monnier
2016-02-21 10:05 ` Philipp Stephani
3 siblings, 1 reply; 35+ messages in thread
From: Stefan Monnier @ 2016-02-21 2:18 UTC (permalink / raw)
To: emacs-devel
> 1. Not only emacs provides a package manager. Linux distributions also
> provide some packages. Not sure if this is a good idea.
> The same situation is e.g. for python. You can use pip to install
> packages. And there are python packages provided by distributions.
> Some people prefer OS packages, some prefer the native package manager.
> Not sure what to do about this situation.
It's easy to make a .deb package which installs an Elisp package in the
way package.el would have installed it (but with global scope).
The two aren't 100% equivalent (upgrading/removing a dpkg-installed
package via package.el won't do the right thing), but the Debian
packages can easily do better than what is there now.
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: Future role of ELPA
2016-02-21 2:18 ` Stefan Monnier
@ 2016-02-21 10:05 ` Philipp Stephani
2016-02-21 14:19 ` Stefan Monnier
2016-02-21 23:37 ` Richard Stallman
0 siblings, 2 replies; 35+ messages in thread
From: Philipp Stephani @ 2016-02-21 10:05 UTC (permalink / raw)
To: Stefan Monnier, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> schrieb am So., 21. Feb. 2016 um
03:19 Uhr:
> > 1. Not only emacs provides a package manager. Linux distributions also
> > provide some packages. Not sure if this is a good idea.
> > The same situation is e.g. for python. You can use pip to install
> > packages. And there are python packages provided by distributions.
> > Some people prefer OS packages, some prefer the native package
> manager.
> > Not sure what to do about this situation.
>
> It's easy to make a .deb package which installs an Elisp package in the
> way package.el would have installed it (but with global scope).
>
> The two aren't 100% equivalent (upgrading/removing a dpkg-installed
> package via package.el won't do the right thing), but the Debian
> packages can easily do better than what is there now.
>
That would be great, but it would mean the Debian Emacs policy (
https://www.debian.org/doc/packaging-manuals/debian-emacs-policy) and the
emacsen-common package, which provides the necessary infrastructure, would
need to be upgraded.
My understanding is as follows: to build such a Debian package, you'd have
to install the byte-compiled files in a directory with the same name as the
Emacs package, and add its parent to package-directory-list in
site-start.d, is that roughly correct?
[-- Attachment #2: Type: text/html, Size: 1776 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Future role of ELPA
2016-02-21 10:05 ` Philipp Stephani
@ 2016-02-21 14:19 ` Stefan Monnier
2016-02-21 23:37 ` Richard Stallman
1 sibling, 0 replies; 35+ messages in thread
From: Stefan Monnier @ 2016-02-21 14:19 UTC (permalink / raw)
To: Philipp Stephani; +Cc: emacs-devel
> My understanding is as follows: to build such a Debian package, you'd have
> to install the byte-compiled files in a directory with the same name as the
> Emacs package, and add its parent to package-directory-list in
> site-start.d, is that roughly correct?
Something like that, yes. And include <pkg>-autoloads.el and
<pkg>-pkg.el files in there as well.
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: Future role of ELPA
2016-02-21 10:05 ` Philipp Stephani
2016-02-21 14:19 ` Stefan Monnier
@ 2016-02-21 23:37 ` Richard Stallman
2016-02-22 18:00 ` Richard Stallman
1 sibling, 1 reply; 35+ messages in thread
From: Richard Stallman @ 2016-02-21 23:37 UTC (permalink / raw)
To: Philipp Stephani; +Cc: monnier, emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
If we are going to offer our own .deb packages of Emacs, that doesn't
mean we have to follow all of Debian's policies. In general, we
should follow our own policies when they disagree with Debian's.
If you see a practical reason to depart from that, please discuss
it with me.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Future role of ELPA
2016-02-21 23:37 ` Richard Stallman
@ 2016-02-22 18:00 ` Richard Stallman
0 siblings, 0 replies; 35+ messages in thread
From: Richard Stallman @ 2016-02-22 18:00 UTC (permalink / raw)
To: p.stephani2, monnier, emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
I looked at https://www.debian.org/doc/packaging-manuals/debian-emacs-policy.
It involves substantial changes which we don't have a reason to make.
I don't mind that Debian makes these changes for its Emacs packages,
but we don't have to do it when we package the development Emacs.
If you build Emacs from source, on Debian, does that cause conflicts
with Debian's Emacs patches? If not, then there won't be a conflict
if we package Emacs as it stands.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Future role of ELPA
2016-02-16 8:05 ` Future role of ELPA (was: [ELPA] tramp-theme.el) Stefan Reichör
` (3 preceding siblings ...)
2016-02-16 17:52 ` Future role of ELPA John Wiegley
@ 2016-02-17 18:42 ` Phillip Lord
4 siblings, 0 replies; 35+ messages in thread
From: Phillip Lord @ 2016-02-17 18:42 UTC (permalink / raw)
To: Stefan Reichör; +Cc: emacs-devel
Stefan Reichör <stefan@xsteve.at> writes:
>
> I am reading the emacs devel list. And I know that this is the direction
> that is desired by most/all developers.
>
> As I user I am not happy with that direction.
> Let me try to explain it.
> I use Emacs since about 20 years. I use it daily and it is my primary
> interface to computer related tasks. For sure I can adopt to what ever
> direction emacs goes.
>
> I use a hand crafted .emacs and I am used to install emacs packes
> manually to a site-lisp folders.
I stopped doing that in favour of use a package-install statement, in
this case via use-package. In total this means that,
(require 'feature)
get replaced by
(use-package feature :ensure t)
There's even a way to avoid doing the :ensure bit if you want. In the
.emacs, the use of package.el can be pretty invisible.
> Consider a simple customization like tramp-theme. When everything is in
> stock emacs: I just can change the value of a customization variable and
> see what happens.
One thing that is an issue with package.el as it stands is
discoverability. Currently, if I open a *.lua file, I get fundamental
mode. While if I open a *.python file, I get python mode. Clearly the
former is unfriendly, and nothing tells me that installing lua-mode
solves the problem. If python-mode (for example) moved to ELPA, then
clearly we'd have the same problem there.
I think that there are two solutions to this: some packages should go to
ELPA, but could be packaged up with an Emacs distribution. Emacs "point"
releases then might have no changes to the core, but just changes to
ELPA packages.
The other possibility would be to have an something like autoloads for
ELPA packages. So, the first time you open a *.py file, and Emacs says
"Do you want to install python-mode".
> With GNU ELPA I have to install the package first and get rid of it if I
> don't like it.
Just leave it -- disk space is cheap!
> My main concern with GNU ELPA is that I have to install a lot of extra
> packages manually using the package manager. When they are built-in they
> are just there.
>
> So I hope that many useful features will still be shipped with Emacs as
> integrated packages.
I would modify this to "I hope that many useful features will continue
to be as usable as currently". Do you really care about whether they are
integrated, or if they just appear to be but some magic is happening
somewhere.
Phil
^ permalink raw reply [flat|nested] 35+ messages in thread