>>"Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
Anthony> Drawing the line at the package level gives you a nice way
Anthony> of thinking about our current arrangements: Depends: ensure
Anthony> against complete failure whenever possible (contrib packages
Anthony> and kernel modules being the notable exceptions), leaving a
Anthony> trade-off between splitting packages or allowing for
Anthony> degraded functionality which the maintainer gets to
Anthony> consider. In the case of cardmgr and apt-preconfigure,
Anthony> degraded behaviour was considered the lesser evil than
Anthony> having an extra couple of trivial packages.
There is also the matter of perception (quality of
implementation is a subjective matter). The way it works is this:
If a prorgram does not work (and a link failure is as classic a
definition of does not work as one can get), the program is
broken. If the program is broken, the package is broken (perhaps
partially broken, but broken it is).
Recommended and Suggested packages are supposed to be
optional. Nt having optional packages installed ought not to cause
programs to break.
Anthony> What, exactly, is the difference between having a package
Anthony> "foo" provide two binaries "foo" and "xfoo", the former of
Anthony> which is what most people who use the package care about and
Anthony> always works, and the latter of which only works if the
Anthony> xlibs package is installed; and a package "bar" having a
Anthony> single binary "bar" that has a "-x" mode that pops up a GUI
Anthony> but dies with an error when the X libraries aren't
Anthony> installed. How is the latter a "graceful degradation" but
Anthony> the former not?
The difference? Perception.
Hmm. Consider this scenario: I am out in the field (client
site, airport) with no connectivity. If an option -x does not work, I
say, huh, lemme try it without that option, and I go on.
Now, if foo is advertised as an alternative for xfoo, I can
see why that is not a big deal (I'll consider the program broken, but
the package is not in such a bad state): I'll use foo instead.
However, if a program exists, that just does not work, and there is
no advertised alternative, well, that is incredibly
frustrating. Nothing I can do on the machine can make the program
work.
The package would be deemed to be broken (read buggy) in
either case, but yes, there is a difference, with an advertised
alternative, or if the breakage occurs only on some options, the
impact of the bug is less.
A perception of quality is one of the most treasured
attributes we have garnered, in the eyes of the public, random
program breakage would tarnish that.
Anthony> "Programs" is not a good division to make. "Packages"
Anthony> is. "Features" is. What's a "program" and what isn't is an
Anthony> implementation detail, and little more.
But people interact with programs, really, not packages. We
had an invariant: set up a package right, and things work as
advertised. Now, we say, install all possible optional dependency
packages, and all that they recommend/suggest, and then maybe,
programs you just installed may work.
manoj
--
The worst thing about some men is that when they are not drunk they
are sober. William Butler Yeats
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]
