Le Mar 11 Avril 2006 15:08, Goswin von Brederlow a écrit : > > 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 ?
> I think that circle is unavoidable.
right, I forgot about the dpkg conflict bug.
but we will need a way to have an answer to that kind of problem.
kdelibs had it (and currently we have merged the -bin into the kdelibs
package, which is eluding the problem rather than fixing it), now libc
faces it, and I think many libs may. the point is that with multiarch,
you still can have only *one* version of the binaries.
So maybe the famous looooong standing bug will have to be fixed one way
or another, because it's the only clean way I see to avoid loops (using
a conflicts instead of a looping depends). With that fixed, we could
use ${shlibs:Conflicts} for -bin packages that are to be tied to some
lib package.
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> > libc6 preinst calls /usr/bin/ldd to know which ld_so is used on the
> > system. that means that libc-bin has to be extracted *before* libc6
> > is. Though, that part seems to be quite brittle, and I assume we
> > could use another tool than
>
> That wasn't mentioned in the mail, only ldconfig. I can't see why
> preinst would need to call ldd, after all the ld.so should be the
> same accross the arch and is hardcoded into every binary, including
> libc6 itself. Why isn't that probed during build time? Might be
> tricky on cross compiles but otherwise it is trivial.
>
> Will dpkg run both libc6.preinst and libc-bin.preinst before
> unpacking either of them or run preinst and unpack each of them in
> turn?
>
> Worst case it needs a /usr/lib/libc6/ldd.arch-os in libc6.deb and
> call that directly.
we agree on this, it's a problem I've spotted dowgrading from a
libc6+libc-bin to the current libc6 scheme (that's a good way to know
what may cause a problem the upgrade).
The ldconfig problem was obvious, this one a bit less ;) still, it may
suck if there some scenario where preinst of current libc6 could be
used instead of the new one (I'm a but rusty on my maintainer scripts
call interleaves... and have not checked if it's possible). If not,
then that can be dealt with like you said, else we will have to take
care of ldd, because of the current preinst script.
> > else, you are right, the only thing we have to be sure, is that *a*
> > libc-bin is extracted before libc6 postinst runs, and that should
> > always be OK, since libc6 depends upon libc-bin.
>
> When doing a full upgrade (stable->unstable) could it happen that apt
> breaks the libc6<->libc-bin depends cycle and put them into seperate
> dpkg calls? I don't remember how smart/stupid libapt was there. It
> might be best to add "apt-get install libc6 libc-bin" to the upgrade
> instructions.
like said, there is an easy way to solve that problem for good: put
ldconfig/ldd into a "ldconfig" pacakge, that libc6 *and* libc-bin will
depend upon. no circular dependency is needed, and we can also be sure
it will always be pulled in before libc6 is.
and libc-bin other things still can remain in a separate package to
prepare multiarch[1], nothing really vital for the packaging system
remains in it.
[1] and please, the fact that multiarch will or will not happen for etch
is not relevant, having a multiarch libc *is* a vital step in the
multiarch direction, and that has to happen the soonest possible
--
·O· Pierre Habouzit
··O [EMAIL PROTECTED]
OOO http://www.madism.org
pgpGIbO5fQDuh.pgp
Description: PGP signature
