Re: QA pop quiz

[Colin Watson <cjwatson@debian.org>]

On Wed, Nov 14, 2001 at 05:14:05PM +0100, Marcelo E. Magallon wrote:
>  This one is open book, use whatever resources you want to find an
>  answer, but provide sources for any quotation (Colin, you still owe me
>  that PCR source).

I don't know of a source for the composite Provides/Conflicts/Replaces
trick, but it's easy enough to build it up from the definitions of each
of those fields. Policy 7.5.2 says that Conflicts/Replaces allows one
package to say that another should be removed, and renaming is identical
to introducing a new package which forces the old package to be removed.
It's an easy step to see that renaming must involve
Provides/Conflicts/Replaces if you want dependencies to continue to
work. (If versioned dependencies must continue to work, of course, a
dummy package is required, until such time as we have versioned
provides.)

I see one use of P/C/R in the policy manual, again in section 7.5.2,
although its use is somewhat different and involves mutually conflicting
mail-transport-agents.

That said, although dpkg's "considering removing foo in favour of bar"
message is triggered by Conflicts/Replaces, dselect doesn't yet
understand Replaces.

>  A package has or is the source of interoperability problems.  What
>  should the bug severity be set to?  Consider other Linux distributions
>  as well other Unix implementations.

PS noted, but I'd have to take the easy way out and say "not enough
information" here. There are situations where interoperability problems
will render a package mostly unusable: say Debian's NFS client software
broke interoperability with Solaris' NFS server, for example.
Considering the number of sites where Solaris is chosen as the NFS
server, this would be fair justification for 'critical' or 'grave'.

Serious? Well, it depends on the source of the interoperability, but
this severity probably only applies if the interoperability is an
explicit policy violation (e.g. the package uses the wrong location for
the mail spool). I think this would be more likely if the package fails
to interoperate with other Debian packages, or if the interoperability
is due to it being a violation of some specification (say, it's a news
server that fails to handle dot-stuffing correctly) than if it fails to
interoperate with software on other systems for more ordinary reasons.

For most such problems, I would be liable to pick 'important' or
'normal', depending on the degree to which things break due to the bug.
Examples of these might include Debian's ssh client being unable to talk
to some particular commercial ssh server, or tar producing archives that
can't be read by some other tar implementations.

Is that a specific enough answer? I have a feeling you meant something a
little less general than that.

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]