On Sat, Apr 27, 2002 at 11:07:52AM -0500, Manoj Srivastava wrote:
> 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.
By comparison, complete failure of the pcmcia-cs package would be not
being able to use PCMCIA cards. Having some GUI tool fail to work by
comparison is mereley degraded functionality. Whether you'd consider that
"graceful" or not is another matter entirely.
Drawing the line at the package level gives you a nice way of thinking
about our current arrangements: Depends: ensure against complete failure
whenever possible (contrib packages and kernel modules being the notable
exceptions), leaving a trade-off between splitting packages or allowing
for degraded functionality which the maintainer gets to consider. In the
case of cardmgr and apt-preconfigure, degraded behaviour was considered
the lesser evil than having an extra couple of trivial packages.
> 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.
Uh, I think you'll find most end users consider the pcmcia-cs package to
not work iff PCMCIA cards aren't correctly recognised.
> 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.
Then maybe you should start questioning that conviction.
What, exactly, is the difference between having a package "foo" provide
two binaries "foo" and "xfoo", the former of which is what most people
who use the package care about and always works, and the latter of which
only works if the xlibs package is installed; and a package "bar" having
a single binary "bar" that has a "-x" mode that pops up a GUI but dies
with an error when the X libraries aren't installed. How is the latter a
"graceful degradation" but the former not?
> >> 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.
"Programs" is not a good division to make. "Packages" is. "Features" is.
What's a "program" and what isn't is an implementation detail, and
little more.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
Attachment:
pgpAt7f80nVF6.pgp
Description: PGP signature