emacs-devel
[Top][All Lists]
Advanced

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

Re: Bundling GNU ELPA packages with Emacs - what are we missing?


From: Stephen Leake
Subject: Re: Bundling GNU ELPA packages with Emacs - what are we missing?
Date: Thu, 10 Sep 2020 12:49:01 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (windows-nt)

Michael Albinus <michael.albinus@gmx.de> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
> Hi Stefan,
>
>> One thing I noted is that `M-x list-packages U' doesn't mark built-in
>> packages for upgrading even when there is a newer version available from
>> GNU ELPA.  Perhaps that's by design?  If not, it just sounds like a bug
>> to fix.
>
> Sorry to be the grinch, but I'm not sure this shall happen by
> default. For example, Tramp is built-in in Emacs, and it exists also as
> GNU ELPA package. Many people don't use it; why shall they be forced to
> upgrade?

They asked for a list of _possible_ upgrades; they can then unmark
packages they don't want to upgrade.

It might help if there was a mechanism to freeze packages, so no
upgrades are suggested for packages that are frozen.

> And, as said otherwere already, such an upgraded Emacs is different
> from an Emacs started via "emacs -Q". For Tramp, it is essential to
> analyze problems with an Emacs started as "emacs -Q". We would loose
> this possiblitiy.

Actually, it is essential for the user reporting a problem and the
maintainer diagnosing it to be using the same versions; that's normal
for ELPA packages. It requires all relevant details in the bug
report, and ways to start emacs with the relevant versions; -Q may do
that, but for ELPA packages it needs to be followed by loading the
relevant packages.

-- 
-- Stephe



reply via email to

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