Subject: bug#77075: [PATCH] Prepare package.el to be published on GNU ELPA, [PATCH] Prepare package.el to be published on GNU ELPA

From: Daniel Mendler <[email-masked]>
Date: Wed, 19 Mar 2025 18:01:54 +0100

Philip Kaludercic <[email-masked]> writes:

> Stefan Monnier <[email-masked]> writes:
>
>>>> I'm worried that our standard practice is being polluted by other
>>>> systems where it's routine to force all users to constantly upgrade
>>>> everything (which I believe ultimately erodes the freedoms offered by
>>>> Free Software), so I think it's important that the packages over which
>>>> we have some control preserve the tradition of being careful to keep
>>>> dependencies no stricter than necessary.
>>>
>>> Could you perhaps briefly explain the philosophical argument?
>>
>> Not sure what you mean by that, but if you want me to explain why
>> I think it erodes Free Software: in systems like Rust/Go/JS where
>> dependencies tend to be very tight, it becomes a lot more difficult to
>> maintain local changes to a piece of code, because pretty quickly none
>> of the rest of the "world" will work with the version of the package FOO
>> you modified, so either you stick to an old snapshot of all the packages
>> (i.e. "stuck in time") or you have to port your change to a newer
>> version of FOO (i.e. live on the bleeding edge).
>>
>> If you push the precise-version-dependency argument to its logical
>> conclusion, packages should even refuse to work (unless you modify them,
>> that is) with your locally modified version of FOO because, well, they
>> haven't been tested against your version of the package, have they?
>> Their coders wouldn't want to receive bug reports about people using
>> their package with your modified FOO.
>
> In that case I misunderstood what you are referring to, but I agree that
> it is a relevant concern.  If you think it is worth it, I can check if
> reducing the version of Compat is feasible, or if that would just
> require the introduction of too many kludges.

We should not introduce kludges in order to reduce the version
requirements. As Stefan argues, it is best to require the version of a
dependency such that all necessary features are provided, but not
unnecessarily depend on newer versions "just because".

While I understand and share Stefan's arguments and concerns in general,
and the problems in other systems like Rust/Go/JS, I find it a bit
misplaced to bring them up in this particular case. We have made Compat
specifically to make it easier for package authors to support older
Emacs versions, which arguably increases freedom for the users.

Daniel