Re: Technical Committee: decision on #119517?
Manoj Srivastava writes (SuperCite undone):
> Ian Jackson:
> > 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.
>
> If I install a package properly, all dependencies satisfied,
> all binaries work. Added recommended or suggested packages may
> enhance functionality; but the b i n a r i e s M U S T w o r k.
Err, that's a more general restatement of what I said, isn't it ?
I'm afraid I still don't understand what is special about a feature
that's invoked by running a separate program, as opposed to a feature
invoked by a keystroke sequence, menu option, or command to a
program's built-in CLI.
I'm not sure whether this paragraph ...
> Nope. The objection is that a package presents an interface to
> a user to added functionality, and binaries provided by a package are
> the user interface most commonly seen by users towards that. Any
> binary that fails is a bug in the package. Mitigating factors are
> that a package may not be properly installed.
... is supposed to be an answer to that question, but I'll try to
treat it as one.
In many packages, there is one main program. In those packages, the
interface people use to discover the functionality provided is to use
the user-interface features and on-line help of the program itself.
So it seems to me that if you forbid having programs installed which
do not work, you must even more strongly forbid having menu options or
what-have-you that don't work. But that's the opposite of your
position as I understand it.
> No. The suggestion, which you apprently did not follow, was to
> provide core functionality of the program regardless of X, and added
> functionality when X libs are present. In other words, the program,
> the interface the user sees, actually does something.
Does the provided cardctl program not provide an text-mode interface
to the same information as cardinfo ? I agree that it's not as
friendly, and that it might be nice if there was something a little
easier to use, but if such a thing were written it IMO ought not to be
called `cardinfo'.
> I disagree strongly. This is a quality of implementation
> issue. When I go on a machine, fire off a binary, and it faults, I
> know the machine is broken.
You say it `faults'. To me that would mean that it receives a signal
whose default action is to terminate and dump core - SIGSEGV or SIGBUS
or the like. It doens't do that. It prints an informative error
message and exits nonzero, just like gxditview:
-norway:~> really cardinfo
cardinfo: error in loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory
-norway:~> echo $?
127
-norway:~>
I'm not sure why you see this as a totally unacceptable behaviour, but
the behaviours of cron, minicom and fvwm as fine. For example, fvwm
does this if you run it without m4 installed:
-norway:~> fvwm -cmd 'FvwmM4 .fvwmrc'
sh: m4: command not found
[ and then it runs with an empty config file using builtin defaults ]
> Suggests does nto mean install suggested packages, or else
> some binaries are just going to fail. Why the hell have a dependency
> system with differeing levels at all, if you can no longer be sure
> what one needs install in order to have binaries work?
The dependency system is intended to make *packages* work. The
different levels of dependency are there precisely to allow different
subsets of a package to be made to work, without having to split
packages up unnecessarily.
> Really? I would rahtter add one more package to the nearly 10k
> list than have broken systems all over the place.
You keep saying you think a system with cardinfo but not X libraries
is broken. If I considered it as broken as you do then I'm sure I'd
agree that it was bad and ought to be avoided even if doing so has
substantial costs.
Can you explain why you think this is such a terrible situation ?
I understand that the binary does not work in this configuration, but
I don't understand why you think this is flat out unacceptable. What
actual bad consequences are there ?
> yeah, it just makes sure that programs in debian kinda work,
> rather than be discovered randomly after the install phase is over,
> and one no longer has access to the install system. That is
> ridiculous.
Note also that even if we made cardinfo a separate package, or
arranged for the dependency to enforce the installation of the X
libraries, you still wouldn't be able to run cardinfo on a system with
no X installation because you'd have no display !
> > * cron Recommends mail-transport-agent. [...]
> > * fvwm Suggests m4. [...]
> > * minicom Suggests lrzsz. [...]
> > * groff contains gxditview, [...], but only Suggests xlib6g.
>
> Every single one of these packages the program can be
> used. They are, (voila!) working. Add suggested packages, they can do
> extra things, work better. But the base code does more than produce
> error messages.
These things are all true of pcmcia-cs. The base code - cardctl and
friends - does more than produce error messages.
Most puzzling to me seems to be your position on groff. It's clear
that if you install groff the base code does indeed work. But you're
saying that there should be no non-working binaries, and if you
install groff without xlib6g you get a non-working binary (and indeed
there's no alternative sensible ditroff previewer). I was expecting
you to say that gxditview should be broken out of groff, too.
ian@xenophobe:~$ /usr/X11R6/bin/gxditview
/usr/X11R6/bin/gxditview: error in loading shared libraries: libXaw.so.6: cannot open shared object file: No such file or directory
ian@xenophobe:~$ echo $?
127
ian@xenophobe:~$
Ian.
--
To UNSUBSCRIBE, email to debian-ctte-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: