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 [EMAIL PROTECTED]
