On Sun, Oct 12, 2003 at 12:01:11AM +0200, Bj?rn Stenberg wrote: > Steve Langasek wrote: > > Ok. BTW, are you taking into account the possibility of a package being > > uninstallable due to versioned Conflicts, and Conflicts between packages > > which otherwise satisfy a package's dependencies? > > I have now added versioned conflict scanning and also checking for packages > which depend on versions older than the ones about to be installed. > > To make packages with these problems easier to find, there are two new lists: > > http://bjorn.haxx.se/debian/conflicts.html > http://bjorn.haxx.se/debian/olddeps.html > > It is not obvious to me how (or if) I can recognize a "bad" versioned conflict > from a "good". For instance, lvm10 conflicts with lvm2 << 1.95.15-3 while the > lvm2 version in testing is 1.95.15-1. Is this simply a case of lvm10 > superseding lvm2, and nothing I should warn about? If so, how can I tell?
What's bad is if a package, taken on its own, is uninstallable. It's not bad (from britney's point of view) if combinations of packages without direct dependency relationships between them are uninstallable. So, bad: Package: foo Version: 1.1 Depends: bar Conflicts: bar (<< 2.0) Package: bar Version: 1.1 Not bad: Package: foo Version: 1.1 Conflicts: bar (<< 2.0) Package: bar Version: 1.1 In the first example, the fact that foo depends on bar while simultaneously conflicting with the version of bar in the suite you're looking at is the thing that's bad, because it means foo can't be installed. The second example is OK, even though foo and bar can't be installed simultaneously; in an ideal world we might check that one of them is Priority: extra, but there's a bit too much other stuff going on for this to be feasible right now. These examples are a bit contrived, but there are certainly real cases in the archive. Cheers, -- Colin Watson [EMAIL PROTECTED]
