GNU bug report logs - #26490
25.1; package-buffer-info is incorrectly case-insensitive

Previous Next

Package: emacs;

Reported by: Steve Purcell <steve <at> sanityinc.com>

Date: Fri, 14 Apr 2017 00:46:02 UTC

Severity: minor

Found in version 25.1

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Kangas <stefan <at> marxist.se>
To: Steve Purcell <steve <at> sanityinc.com>
Cc: 26490 <at> debbugs.gnu.org
Subject: bug#26490: 25.1; package-buffer-info is incorrectly case-insensitive
Date: Sat, 28 Sep 2019 12:55:09 +0200
[Message part 1 (text/plain, inline)]
Steve Purcell <steve <at> sanityinc.com> writes:

> >> Nonetheless, it has been part of the format expected by package.el for years.
> >>
> >> Making package.el more permissive over time can lead to problems with packages
> >> in older Emacsen, a prime example being the recently-added
> >> backwards-incompatible support for version-less dependencies in the
> >> `Package-Requires` header: authors check their packages in a recent Emacs and
> >> then find that an older otherwise-compatible Emacs can’t even parse their
> >> package metadata.
> >
> > Sure, that can be a problem.  I think that means that we should not
> > (yet) encourage package developers to not use them in their packages.
> > But if we don't take a first step, we can never get rid of it.
>
> > At the end of the day, it's the job of package developers to maintain
> > backwards compatibility.  I don't see why this change would be any
> > different in that respect from the many other changes that we make
> > between releases.
>
> My point is that if a package file can’t even be parsed by an older Emacs
> version’s “package.el”, the user of that Emacs version will automatically get an
> obscure error when they try to install it, even if the the package author was
> helpful enough to add `(emacs “27”)` as a dependency to indicate
> incompatibility. That’s not something that the package author could reasonably
> foresee, and it feels avoidable by keeping the basic structure of required
> metadata stable and backwards compatible.

I see your point.  How about issuing a warning instead?  That should
be sufficiently discouraging for package authors, while also allowing
us to drop this requirement at some point in the future.

I've attached a patch which I believe would do this in a reasonable way.

Best regards,
Stefan Kangas
[0001-Don-t-refuse-to-install-packages-without-a-footer-li.patch (text/x-patch, attachment)]

This bug report was last modified 5 years and 287 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.