[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