Re: Technical Committee: decision on #119517?
Manoj Srivastava writes ("Re: Technical Committee: decision on #119517?"):
> From reviewing the bug report, Ian Jackson sided with the
> maintainer, with the opinion that not all binaries shipped with a
> package need work when the dependencies are satisfied. Dale Scheetz,
> Jason Gunthorpe, and I disagreed.
...
> I suggest that the quorum of two was met, and that the
> decision of the committee be formalized.
Certainly we didn't vote. Before we vote now I'd like to recap the
issues and make sure we've considered everything. It seemed to me
that we were still discussing the question. In particular, looking at
the bug logs, and recalling what was said before, I think there are
still some unanswered questions.
So, the current situation is as follows:
The package pcmcia-cs contains, amongst many other more important
things, a binary `cardinfo' which is an X program. It declares a
Suggests dependency on the X libraries. The effects of this are:
When you install pcmcia-cs, some UI tools (eg dselect) offer the X
libraries, but none install it by default. If you do not select the X
libraries you still get the binary `cardinfo' installed, but if you
try to run it you get an error from ld.so.
The complaint is that this is wrong, and instead either pcmcia-cs
should Depend on xlib6g, or the X11 cardinfo program should be split
into a separate package. (There was also a fudge suggested, making
cardinfo a wrapper script to do something completely different, to
avoid using X, if xlib6g wasn't present.)
As I understand it, the supposed principle which is being applied is
that it is unacceptable to have a binary in the package which depends
on libraries not mentioned in Depends, and that Recommends or Suggests
are not sufficient. I have two objections to this:
1. I think the current situation is fine. The other suggested
approaches to this issue have much worse effects than a slightly ugly
but perfectly informative error message.
Forcing the user to always install the X libraries with pcmcia-cs is
clearly unacceptable.
Splitting the package up is gross overkill - the general cost of an
additional package to maintain, update, select, install, cope with
dependencies of, find, etc. etc. is considerable. Note that a person
who forgets to install X when they wanted cardinfo is even more likely
to fail to spot the proposed pcmcia-cs-cardinfo package; when they
want to run cardinfo because they heard about it from a colleage
running some other distribution, we serve them better by giving them
the ld.so error message than by making the file vanish !
The only remaining approach suggested was to make cardinfo a wrapper
script which would either invoke the real X cardinfo program, or do
some kind of text-mode alternative if X wasn't available; I think this
is a hideous idea. It is a pointless piece of programming, since it
adds no new functionality or ease of use (people who wanted the text
UI will invoke it directly). It makes our `cardinfo' command behave
gratuitously differently to everyone else's. Finally, by making the
error message go away it hides the real reason why the user isn't
getting the X interface (which is presumably what they wanted), so now
it becomes harder to fix the original problem.
In fact, it seems to me that much of the aim of the complainants here
is to suppress the error message. I think this is a severely
misguided aim. Error messages are often useful and informative.
Trying to get rid of them just because you don't like errors on
principle, or find them ugly, is a road to ruin, certainly when we're
talking about the UN*X command-line.
2. I think the proposed principle is either inconsistent with current
practice, or internally inconsistent (depending how far it goes). Let
me explain:
Is this suggested principle, that binaries' dependencies on shared
libraries should always be declared as Depends:
(a) a special case which applies only to executables' dependencies on
shared libraries, or
(b) just an application of the supposed general principle that we
should declare as Depends all dependencies which, when unsatisfied,
manifest themselves as a straightforward run-time error ?
If you think (a) then I'd be interested to hear an explanation of what
makes dependencies of executables on their libraries different.
If you think (b) - that all dependencies whose violation produces
run-time errors should be declared as Depends - then you're
effectively suggesting abolishing a primary use of Recommends and
Suggests in the distribution.
There are many programs which just fail if you request the use of a
feature which needs an unsatisfied Recommends or Suggests. Some
examples:
* cron Recommends mail-transport-agent. But, cron is supposed to be
able to send mail and can't if you don't install
mail-transport-agent; the messages that cron would send effectively
get lost. However, you can still use cron in this configuration -
you just have to make explicit arrangements in your crontab entries
for capturing the output.
* fvwm Suggests m4. If you install it without m4 but ask for to
m4-preprocess your file, it will fail.
* minicom Suggests lrzsz. If you install it without, you can still
use it, but the rz/sz file transfer commands will not work.
* groff contains gxditview, which is an X program, but only Suggests
xlib6g.
If abolishing this kind of thing is really what's intended, then this
should surely be stated clearly and discussed on debian-policy first.
But, as I say in 1. above, I think this is a very bad idea.
Ian.
--
To UNSUBSCRIBE, email to debian-ctte-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: