Re: Bug#30739: When a tiny part of a package uses non-free libraries
Kevin Dalley <firstname.lastname@example.org> wrote:
> One of the wonderful things about Debian is that installation of a
> package includes installation of any needed libraries. The average
> user *never* needs to install a library by itself. We should keep
> those standards. I like cardinfo, but I would still use cardinfo if
> it were in contrib.
This is incorrect. Packages currently in the distribution can and do
"Suggest" library packages required for some of their applications to
run, and I have yet to see anything in the Debian policy documents that
expressly forbids this practice. The reason that you are not aware of
this is that usually the executables that have this problem are rarely
used and provide some sort of extra functionality, such as
configuration or an X interface.
Besides, is there any difference from the users point of view of a
binary linked to a library that is not installed and a script written
for an interpreter that is not installed? There are many examples of a
package which includes a small script (e.g., written in python or wish)
which provides a graphical front-end or configuration program for a
non-graphical application. Do we require all of these packages to
"Depend" on the X libraries? Or do we clutter up the packaging system
with a bunch of stupid little packages with tiny scripts? It is my
opinion, that both of these options are unacceptable.
> I also recently installed Debian on a new laptop. I was confused
> about libforms not being installed even though cardinfo was there.
> Of course, I could figure out what to do. Adding documentation in
> the description is not good enough. You shouldn't have to read the
> documentation install a library, especially when we have tools smart
> enough to make this automatic. See _The Design of Everyday Things_,
> by Norman.
The comment about cardinfo would not be placed in the documentation,
but in the description of the package (i.e., the "Description" field),
which I hope the user would read before installing it. (Sorry, but
with the cryptic names that many packages use, the description is the
only thing that can tell the user why he should install the package.)
I think that it is entirely appropriate for the description of a
package to explain why it is suggesting another package. At some
point, we will have to interface with the user, and he or she will have
to make a decision. I would prefer it to be an informed one. After
all, you can automate the process only so much.
Samuel Tardieu <email@example.com> wrote:
> why not creating a small cardinfo shell wrapper that prints a clear
> error message if libforms is not installed, and calls the real
> cardinfo if everything looks OK?
This probably would be a good idea and would cut down on some confusion.