Re: Which packages will hold up the release?
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 [cjwatson@flatline.org.uk]
Reply to: