Sven Joachim <[EMAIL PROTECTED]> 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 <[email protected]> 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
