Re: predepends on libc6?
dark@xs4all.nl (Richard Braakman) writes:
> So why did you add the call to ldconfig?
Because it's necessary. Duh. As I say, try removing it from
libreadline2's postinst. Why do you think the upgrade of bo -> hamm
is still so problematic? It's because we don't have a method for
selective immediate configuration, so during upgrade of libreadline2
and libgdbm1 until ldconfig is run perl and bash are fubar. If you
were right, the upgrade to bo -> hamm would be much easier (and Scott
would be out of a job ;-).
> So far you have not given any reasons. In fact, you seem to expect
> me to take your word for it, which is exactly what you object to
> here.
I expect you to take the word of David Engel on it, yes. I also
expect you to take into consideration the bug reports filed against
packages which didn't do it. Am I lieing? Are they all lieing? Did
they make those bug reports up in some big conspiracy against your
precious packaging manual?
> > I also think someone might have noticed by know if this vast
> > majority of shared libraries were doing it wrong; don't you?
>
> Not if the call is merely unnecessary.
Oh for god sakes' if you think it is, please prove me wrong.
Categorically show that it is *never* necessary to run ldconfig.
I dare you.
> > BTW, even David, the ld.so author & maintainer, says the packaging
> > manual is wrong; are you *so* confident you're right and everybody
> > else is wrong that you're going to tell him he's wrong too?
>
> I am not confident that I am right.
Woo woo.
> I am not confident that the packaging manual is wrong.
Why is it you are so obsessed with the packaging manual? Are you so
convinced it's never wrong?
> Confidence is what one has after examining the arguments, of which
> you have not provided any.
Oh, FFS, neither have you. What I have done is pointed you to the
fact that over 90% of shared libraries do it, that many bugs have been
filed against packages which didn't do it, and that the damn ld.so
author and maintainer says it's the right thing to do. *You* have
whined about the packaging manual saying it's not right. Now tell me,
who has presented less in the way of evidence?
> David Engel said: (#14212)
> | The policy manual is wrong. ldconfig should be called from the
> | postinst script. This is the only way to get the new library listed
> | in /etc/ld.so.cache, which is a must if the library isn't in /lib or
> | /usr/lib.
>
> Obviously, this does not apply to libraries which install in /lib or
> /usr/lib, such as libc6.
hilfy|18:48:39 ~ $dpkg -c /debian/hamm/hamm/binary-i386/interpreters/libguile2_1.2-3.deb
[...]
lrwxrwxrwx root/root 0 1997-10-30 06:48 usr/lib/libguile.so.2 -> libguile.so.2.0.0
-rw-r--r-- root/root 396892 1997-10-30 06:48 usr/lib/libguile.so.2.0.0
Oh really? (#14212 is against libguile2)
> > I give up.
>
> So soon? We have strayed quite a way from my original question:
> what is it that the libc6 postinst does, that makes it necessary for
> gzip to pre-depend on it?
I wasn't responding to that, I was responding to your bogus defence of
the packaging manual.
> If libc6 could be restructured so that this is not necessary, then
> we can lose a whole lot of predependencies in one swoop.
You're drastically missing the point (but hey, what's new). If gzip
only depends on libc6 it's entirely possible for a libc6-based gzip to
be unpacked *before* libc6. dpkg will then move on to the next deb to
install, try to spawn gzip and fail miserably (gzip is linked with a
non-existent libc6), everything falls apart rapidly from there. gzip
*MUST* pre-depend on libc6.
(To be more explicit (since that seems to be the order of the day),
I'm imagining a situation of a person upgrading from bo to hamm doing
something like this:
dpkg -iEGOB gzip_1.2.4-18.deb ae_962_15.deb bc_1.04-2.deb <blahdeblah> libc6_2.0.5c-0.1.deb
When dpkg tries to fork gzip -dc to unpack ae, it fails because libc6
isn't even unpacked yet. With a Pre-Depends this wouldn't happen,
because gzip wouldn't even be unpacked before libc6 is installed (and
configured, *but that's irrelevant here*)
[dpkg does ordering on configuration and removal, not install]
> I do agree that gzip should get the predependency, since it doesn't
> make sense for it to be inconsistent with all those other packages.
Now that is the single most lame reason I've yet to hear for a package
to have a Pre-Depends:.
> Of course, we still need new text for the packaging manual. Try as
> I might, I can not find a bug report to dpkg that addresses this.
Maybe there never was one, I said it was a long standing bug, not bug
report. (Something you apparently missed).
--
James
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: