>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> 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.
Ian> Err, that's a more general restatement of what I said, isn't it ?
Not quite. It is specifying a general principle, leaving the
details of library dependencies out; it does not matter if the
program does not work if it needs another program, script, data
directory, configuration file, or shared library in order to
work. Shared libraries are not special.
Ian> I'm afraid I still don't understand what is special about a feature
Ian> that's invoked by running a separate program, as opposed to a feature
Ian> invoked by a keystroke sequence, menu option, or command to a
Ian> program's built-in CLI.
This is what us folks in the reliability field call the
distinction between complete failure and graceful degradation: the
former case, the program does not work, in the later case it works,
perhaps with reduced functinality.
Ian> So it seems to me that if you forbid having programs installed which
Ian> do not work, you must even more strongly forbid having menu options or
Ian> what-have-you that don't work. But that's the opposite of your
Ian> position as I understand it.
Nope; what do you think the definition of recommends and
suggests implies? To the end user, it implies that the core
functionality would continue to work, though adding recommended or
suggested packages may allow additional behaviour.
In an ideal world, I would like documentation to reflect that
options that require the recommended packages to be labelled as such.
>> 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.
Ian> You say it `faults'. To me that would mean that it receives a signal
Ian> whose default action is to terminate and dump core - SIGSEGV or SIGBUS
Ian> or the like.
Perhaps I should have said fails.
Ian> It doens't do that. It prints an informative error message and
Ian> exits nonzero, just like gxditview:
Ian> -norway:~> really cardinfo
Ian> cardinfo: error in loading shared libraries: libX11.so.6: cannot open
shared object file: No such file or directory
Ian> -norway:~> echo $?
Ian> 127
Ian> -norway:~>
Ian> I'm not sure why you see this as a totally unacceptable behaviour, but
Ian> the behaviours of cron, minicom and fvwm as fine. For example, fvwm
Ian> does this if you run it without m4 installed:
Total failure, with a diagnostic. Nothing I can do can change
this, unless I install suposedly optional packages.
Ian> -norway:~> fvwm -cmd 'FvwmM4 .fvwmrc'
Ian> sh: m4: command not found
Ian> [ and then it runs with an empty config file using builtin defaults ]
And it works. Not ideally, but it did not dump me back to the
login screen. I can now put in place a second config file, which does
not need m4, and it shall work even better -- perhaps not all the
bells and whistles I might have, had I installed m4, but hey. It WORKS!!
>> 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?
Ian> The dependency system is intended to make *packages* work. The
Ian> different levels of dependency are there precisely to allow
Ian> different subsets of a package to be made to work, without
Ian> having to split packages up unnecessarily.
Pedantry. To the end user, a package does not work when the
included binaries do not work. Graceful degradation ius acceptable,
total and complete failure is not. The latter is, for most people,
synonymous with ``the package is broken''.
>> Really? I would rahtter add one more package to the nearly 10k
>> list than have broken systems all over the place.
Ian> You keep saying you think a system with cardinfo but not X
Ian> libraries is broken. If I considered it as broken as you do
Ian> then I'm sure I'd agree that it was bad and ought to be avoided
Ian> even if doing so has substantial costs.
Ian> Can you explain why you think this is such a terrible situation
Ian> ? I understand that the binary does not work in this
Ian> configuration, but I don't understand why you think this is flat
Ian> out unacceptable. What actual bad consequences are there ?
Quality of implementation. Failing least surprise. Failure of
the promised invariant that if I install a package, I should expect
the included programs to work. I am not sure how to get my conviction
that having broken programs when all dependendcies are satisfied is a
horribly bad idea across.
>> 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.
Ian> Note also that even if we made cardinfo a separate package, or
Ian> arranged for the dependency to enforce the installation of the X
Ian> libraries, you still wouldn't be able to run cardinfo on a system with
Ian> no X installation because you'd have no display !
>> > * cron Recommends mail-transport-agent. [...]
>> > * fvwm Suggests m4. [...]
>> > * minicom Suggests lrzsz. [...]
Hmm. gxditview does not belong here anyway.
>>
>> 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.
Ian> These things are all true of pcmcia-cs. The base code - cardctl and
Ian> friends - does more than produce error messages.
No, in the cases above, every program worked. In the latter
case, this is not true.
Ian> Most puzzling to me seems to be your position on groff. It's clear
Ian> that if you install groff the base code does indeed work. But you're
Ian> saying that there should be no non-working binaries, and if you
Ian> install groff without xlib6g you get a non-working binary (and indeed
Ian> there's no alternative sensible ditroff previewer). I was expecting
Ian> you to say that gxditview should be broken out of groff, too.
Strawman. The situation is not as you describe; it seems that
groff suggests groff-x11, and lets see here:
Package: groff-x11
Description: GNU troff components for the X Window System
This package contains the X75, X75-12, X100, and X100-12 groff devices,
which allow groff output to be conveniently viewed on an X display using
the standard X11 fonts. These devices display their output with gxditview,
which is also included here. gxditview can also be used to view PostScript
output from groff.
.
With this package installed, 'man -X' can show man pages in a graphical
window.
It seems current practice for groff is to do as Dale and I recommend.
manoj
--
We are Microsoft. Unix is irrelevant. Openness is futile. Prepare
to be assimilated.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
