Chris Metzler wrote: > But that's the best way it can play out. The worst way -- which is > thankfully uncommon, but can and does happen -- is if Depends or > Conflicts don't catch the problem. An example: package A in stable > requires libfoo version 2.4 or greater; user installs package B, which > requires libfoo version 3.1, and so that gets brought along, replacing > v2.4; package A isn't marked for removal because 3.1 > 2.0; but > software compiled against libfoo v2.4 chokes with libfoo v3.1, and so > the binaries in package A are now broken). The package manager for > libfoo can't set Conflicts: for *everything* compiled against earlier > versions of libfoo because libfoo is just too commonly used. And if > this happens with something like glibc, you're hosed. This scenario is always a bug in libfoo for breaking backwards compatability without changing its soname, and Debian has plenty of standard ways to deal with it that don't involve conflicting with lots of packages. If you see something like this, file a bug report. -- see shy jo
Attachment:
signature.asc
Description: Digital signature