Re: Technical Committee: decision on #119517?

[Manoj Srivastava]

>>"Anthony" == Anthony Towns  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]>  
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]

Re: Technical Committee: decision on #119517?

[Colin Watson]

On Sat, Apr 27, 2002 at 11:07:52AM -0500, Manoj Srivastava wrote:
> >>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
>  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:

Ian is referring to the version in stable, where gxditview was indeed
part of groff.

I split the groff package for other reasons (primarily removing large
components that few people use from the base system) about a year ago,
forming groff-base and groff. At that point, gxditview became a much
more significant part of the groff binary package in relative terms, and
I felt that a stronger relationship than 'Suggests' was appropriate.
However, adding that to groff would have meant that people upgrading
from a potato base system would have found themselves prompted to
install X, which didn't seem ideal to me.

I'm inclined to merge groff-x11 back into groff after woody. I haven't
yet decided what relationship groff should then declare on XFree86, but
I'd imagine that the Committee's decision here will be relevant.

[Hoping to provide useful information here; excuse me for intruding.]

-- 
Colin Watson (groff maintainer)[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Technical Committee: decision on #119517?

[Anthony Towns]

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 <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 ``BAM! Science triumphs again!'' 
-- http://www.angryflower.com/vegeta.gif


pgp3LW0mkKvq4.pgp
Description: PGP signature