Le Mar 11 Avril 2006 12:09, Steve Langasek a écrit : > On Tue, Apr 11, 2006 at 11:51:26AM +0200, Pierre Habouzit wrote: > > Le Mar 11 Avril 2006 11:05, Goswin von Brederlow a écrit : > > > I'm assuming libc6 depends on libc-bin and libc-bin depends on > > > libc6 here. The former is needed to always pull in libc-bin on > > > upgrades and the later is needed to ensure the minimum version > > > requirements as sepcified in libc6.shlibs. We don't want a new > > > libc-bin with a too old libc6. > > > > riiiiight, but that makes a nasty circular dependency I thought we > > should avoid at any rate ? Shouldn't libc-bin rather conflicts with > > bad version of the libc ? > > No. Having libc-bin conflict with libc doesn't help you make sure > libc-bin is pulled into the system, which is what you need. (There > are no "bad versions" of libc here; there are versions that need > libc-bin, and there are versions that don't, and you need some way to > pull libc-bin in for those versions that do need it.) for that problem, what needs libc6 is a depends upon libc-bin. That dependency *has* to stay, and I've never suggested to remove it ;) I was discussing the libc-bin => libc6 dependency, that creates a dependency loop. Goswin argued this was needed to ensure requirements in shlibs. I was proposing to replace that dependency with a conflict with inferior libc6, which breaks the circular dependency, and provides the same properties wrt shlibs requirements. I've also pondered about putting ldconfig+ldd in a separate package, that wouldn't depend upon libc6, since it only holds a script (ldd) and a static binary. but that wouldn't solve the libc6 <=> libc-bin dependency loop anyway. That reminds me a lot of the kdelibs4/kdelibs4-bin problem we had in the KDE team, that had no good answer. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpamuOqIxNlL.pgp
Description: PGP signature