bug#52351: Is bad-packages-alist still relevant?

bug#52351: Is bad-packages-alist still relevant?

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

Severity: wishlist

Is bad-packages-alist still relevant now that we have package.el or
should it just be removed, as in the attached?

It was added in this commit and hasn't seen much use since, AFAICT:

    commit a2603048ce283d22b37b35c9098d4583db244073
    Author: Glenn Morris <rgm@gnu.org>
    Date:   Tue Aug 14 07:41:59 2007 +0000

        (bad-packages-alist): New constant.
        (bad-package-check): New function.  Together, these two add
        elements to `after-load-alist' to check for problematic external
        packages.

The idea is to give warnings for incompatible external packages, but
this should be rather unusual these days, as most packages will be
installed with package.el and any incompatibilities are better handled
in that context.  Furthermore, it seems to currently just warn about
really ancient versions of semantic and cua-mode.

IOW, not a bad idea at the time, but the passing of time has meant that
it's hard to see the relevance of the feature.

[-- Attachment #2: 0001-Remove-bad-packages-alist.patch --]
[-- Type: text/x-diff, Size: 3092 bytes --]

From ed1e061961cfc3eba7d692f93e5fbb70e7df4760 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Tue, 7 Dec 2021 14:46:34 +0100
Subject: [PATCH] Remove bad-packages-alist

* lisp/simple.el (bad-packages-alist, bad-package-check): Remove.
---
 lisp/simple.el | 51 --------------------------------------------------
 1 file changed, 51 deletions(-)

diff --git a/lisp/simple.el b/lisp/simple.el
index 84928caa31..d9845dc3cd 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9783,57 +9783,6 @@ messages-buffer
 ;;  (list 'modification-hooks '(minibuffer-prompt-modification)
 ;;	'insert-in-front-hooks '(minibuffer-prompt-insertion)))
 
-\f
-;;;; Problematic external packages.
-
-;; rms says this should be done by specifying symbols that define
-;; versions together with bad values.  This is therefore not as
-;; flexible as it could be.  See the thread:
-;; https://lists.gnu.org/r/emacs-devel/2007-08/msg00300.html
-(defconst bad-packages-alist
-  ;; Not sure exactly which semantic versions have problems.
-  ;; Definitely 2.0pre3, probably all 2.0pre's before this.
-  '((semantic semantic-version "\\`2\\.0pre[1-3]\\'"
-              "The version of `semantic' loaded does not work in Emacs 22.
-It can cause constant high CPU load.
-Upgrade to at least Semantic 2.0pre4 (distributed with CEDET 1.0pre4).")
-    ;; CUA-mode does not work with GNU Emacs version 22.1 and newer.
-    ;; Except for version 1.2, all of the 1.x and 2.x version of cua-mode
-    ;; provided the `CUA-mode' feature.  Since this is no longer true,
-    ;; we can warn the user if the `CUA-mode' feature is ever provided.
-    (CUA-mode t nil
-"CUA-mode is now part of the standard GNU Emacs distribution,
-so you can now enable CUA via the Options menu or by customizing `cua-mode'.
-
-You have loaded an older version of CUA-mode which does not work
-correctly with this version of Emacs.  You should remove the old
-version and use the one distributed with Emacs."))
-  "Alist of packages known to cause problems in this version of Emacs.
-Each element has the form (PACKAGE SYMBOL REGEXP STRING).
-PACKAGE is either a regular expression to match file names, or a
-symbol (a feature name), like for `with-eval-after-load'.
-SYMBOL is either the name of a string variable, or t.  Upon
-loading PACKAGE, if SYMBOL is t or matches REGEXP, display a
-warning using STRING as the message.")
-
-(defun bad-package-check (package)
-  "Run a check using the element from `bad-packages-alist' matching PACKAGE."
-  (condition-case nil
-      (let* ((list (assoc package bad-packages-alist))
-             (symbol (nth 1 list)))
-        (and list
-             (boundp symbol)
-             (or (eq symbol t)
-                 (and (stringp (setq symbol (eval symbol)))
-                      (string-match-p (nth 2 list) symbol)))
-             (display-warning package (nth 3 list) :warning)))
-    (error nil)))
-
-(dolist (elem bad-packages-alist)
-  (let ((pkg (car elem)))
-    (with-eval-after-load pkg
-      (bad-package-check pkg))))
-
 \f
 ;;; Generic dispatcher commands
 
-- 
2.30.2

bug#52351: Is bad-packages-alist still relevant?

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> IOW, not a bad idea at the time, but the passing of time has meant that
> it's hard to see the relevance of the feature.

Yeah, it doesn't seem very useful to me.  We should probably obsolete
it, though, instead of removing it outright, I guess?  (Even if it's a
defconst.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52351: Is bad-packages-alist still relevant?

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yeah, it doesn't seem very useful to me.  We should probably obsolete
> it, though, instead of removing it outright, I guess?  (Even if it's a
> defconst.)

Sure, we might as well obsolete it.

bug#52351: Is bad-packages-alist still relevant?

[Stefan Kangas]

close 52351 29.1
thanks

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> IOW, not a bad idea at the time, but the passing of time has meant that
>> it's hard to see the relevance of the feature.
>
> Yeah, it doesn't seem very useful to me.  We should probably obsolete
> it, though, instead of removing it outright, I guess?  (Even if it's a
> defconst.)

No further comments within 9 days, so I have now made it obsolete on
master (commit 8f82a83cae).

bug#52351: Is bad-packages-alist still relevant?

[Richard Stallman]

[[[ 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. ]]]

bad-packages-alist may be useful again some day, so please restore its
non-obsoleteness.

The specific issue about Semantic and Emacs 22 is no longer pertinent,
so we should set the variable's default value to nil.

However, that kind of problem could happen again some day.  We hope it
won't, but few of us are perfect and none of us is precognitive.  Why
not be prepared in case such problems occur again?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#52351: Is bad-packages-alist still relevant?

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> bad-packages-alist may be useful again some day, so please restore its
> non-obsoleteness.
>
> The specific issue about Semantic and Emacs 22 is no longer pertinent,
> so we should set the variable's default value to nil.
>
> However, that kind of problem could happen again some day.  We hope it
> won't, but few of us are perfect and none of us is precognitive.  Why
> not be prepared in case such problems occur again?

Beyond the original Semantic case, this hasn't seen much use in 15
years.  If we need it back in the future, we can make it non-obsolete
then.  We have another decade to think about its obsoletion before it
would normally be considered for final removal.