GNU bug report logs - #46236
26.1; explicit the info files installation

Previous Next

Package: emacs;

Reported by: marmot-te <marmot-te <at> riseup.net>

Date: Mon, 1 Feb 2021 14:11:02 UTC

Severity: wishlist

Tags: fixed

Found in version 26.1

Fixed in version 28.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: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: marmot-te <at> riseup.net, 46236 <at> debbugs.gnu.org, rms <at> gnu.org
Subject: bug#46236: 26.1; explicit the info files installation
Date: Wed, 21 Apr 2021 15:16:58 +0300
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Wed, 21 Apr 2021 07:06:47 -0500
> Cc: rms <at> gnu.org, marmot-te <at> riseup.net, 46236 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > That depend on what we say.  We don't have to mention Debian or their
> > repository explicitly -- which would also be better because other
> > distros could have a similar problem.
> 
> I have never seen or heard of any other distribution ripping out the
> manual and distributing it separately from Emacs itself.  Do you know of
> any examples?

It doesn't matter.  I'm saying that we shouldn't name them as a matter
of principle, so as to avoid the few pitfalls you've mentioned, like
talking about non-free repositories.

> When I say `C-h r' without `emacs-common-non-dfsg' installed on my
> Debian machine, I get "Info file emacs does not exist".

We could, for example, say something like

  Info manual for Emacs was not found; consider installing it.

which would be more explicit and clear, I think.

> Perhaps we could just find where that message comes from

It comes from Info-find-file.

> IOW, I think this would be easy to do technically, but it would need us
> to recommend the "non-free" repository.

Which is why I suggest not to name them.

> I'm therefore starting to think that this should be the responsibility
> of Debian.  They should solve the problems that they have created for
> their users; such a warning should be added by *them*.  Doesn't that
> make more sense?

We could indeed decide that it's not our problem.  In fact, the
current situation is tantamount to doing just that.




This bug report was last modified 4 years and 86 days ago.

Previous Next


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