Re: Bug#207932: Consequences of moving Emacs Manuals to non-free
Sven Joachim <svenjoac@gmx.de> writes:
>> Because Emacs is technically able to work without its info manual,
>> so there is no reason for a strong dependency on its documentation.
>
> Maybe it is time to look what the Policy Manual says about dependencies:
>
> `Recommends'
> This declares a strong, but not absolute, dependency.
>
> The `Recommends' field should list packages that would be found
> together with this one in all but unusual installations.
It is a weak dependency regarding dpkg and apt. Only dselect considers
it as a strong one.
> `Suggests'
> This is used to declare that one package may be more useful with
> one or more others. Using this field tells the packaging system
> and the user that the listed packages are related to this one and
> can perhaps enhance its usefulness, but that installing this one
> without them is perfectly reasonable.
It is not a dependency, only an informative "note".
> It is certainly true that Emacs is "technically able to work without its
> info manual", but "technically able" and "perfectly reasonable" are quite
> different things.
I think the later point is moot. The Project decided something
democratically (read: not decided by a single person, hint, hint),
and we have to deal with it.
> Imagine that the manual were already in separate package, but considered
> free by Debian. Would you `recommend' to install it together with Emacs?
> Probably, since Emacs without its info manual would then qualify as an
> "unusual installation".
Let's take the glibc example:
$ dpkg -s libc6-dev
Package: libc6-dev
Status: install ok installed
Priority: standard
Section: libdevel
Installed-Size: 9568
Maintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>
Architecture: amd64
Source: glibc
Version: 2.3.6-3
Replaces: man-db (<= 2.3.10-41), gettext (<= 0.10.26-1), ppp (<=
2.2.0f-24), libgdbmg1-dev (<= 1.7.3-24), ldso (<= 1.9.11-9),
netkit-rpc, netbase (<< 4.0), kerberos4kth-dev (<< 1.2.2-10),
libc6-prof (<< 2.3.5-2)
Provides: libc-dev
Depends: libc6 (= 2.3.6-3), linux-kernel-headers
Recommends: gcc | c-compiler
Suggests: glibc-doc, manpages-dev
As you can see, even libc6 development files "suggest" glibc-doc.
So, suggesting is perfectly OK.
> Of course, having the manual in non-free changes the situation; the
> die-hard freedom advocate who says: "I will never install anything from the
> non-free section, and nobody should do that!" may be willing to use a
> hampered Emacs and not find that unusual. But is it really perfectly
> reasonable?
What exactly do you want? If you are expressing some grumbling about
the outcome of the GR, the point is moot.
Otherwise, what technical solution do you propose? If this is about moving
emacs to contrib, then emacs disappears from Debian (read "main"), and
people have to add contrib to their source list.
> You (and Rob, of course) decide. In any case, I find Miles' statement
> outstanding:
>
>> In practice I guess it's just going to mean that most people end up
>> putting non-free in their sources.list, weakening the effect of having a
>> separation between "free" and "non-free" in the first place, and more
>> users end up confused because lack of hard dependencies will mean the
>> doc packages don't get installed.
>
> That hits the nail on the head. The whole effect of these anti-GFDL
> efforts is to actually undermine Debian's position as a 100% free OS.
(I hate advocating this but ...)
I'm surprised there is still a misunderstanding. Debian decided that
invariant sections were problematic (you will find rationales
everywhere on debian sites). It is not Debian's fault if they do
exist. Furthermore, Debian has been giving feedback to the FSF about
problems in the GFDL for years, but the FSF decided to ignore them.
Hopefull, projects like KDE or GNOME will not suffer from the GR because
they were reasonnable enough not to use invariant sections.
--
Jérôme Marant
Reply to: