James Troup wrote:
> [EMAIL PROTECTED] (Richard Braakman) writes:
>
> > > The packaging manual is wrong; this is a long standing bug.
> >
> > Can you explain, or refer to a bug number that explains it?
>
> No. I have neither the time nor the inclination to trawl through the
> hundreds of bugs filed against dpkg.
I grepped through my bug archive from Jul 19, and I did not find it.
I assume the report will mention "ldconfig" somewhere. I also checked
the current bug report titles on the web, and did not find it.
(I did find a number of "I had problems and you should run ldconfig in
the postinst" bugs, but never any explanation.)
> > It's not very good to have incorrect instructions for shared
> > libraries at a time when we're doing a massive shared-library
> > upgrade.
>
> Most of the libraries have done long ago, and the packaging manual has
> been wrong since before the release of bo.
So now we have to shake out the bugs.
And, of course, we need new text for the packaging manual.
Right now we have "Tinker with the postinst until it seems to work, or
copy one from a similar package". I'd like something more solid.
> > > > Why is it calling ldconfig?
> > >
> > > Because it's the Right thing to do.
> >
> > Heh. That argument only convinces me if I already know why it's
> > Right :-)
>
> Take a look at the postinsts for every package with a shared library.
I did. But why assume they are correct? Someone reports a bug and
says "package should run ldconfig", maintainer says "okey I'll do
that". This does not mean the ldconfig is actually necessary, it may
merely mask the symptoms of a bug in the packaging.
> You seem fond of statistics, how many *don't* run ldconfig?
Of the library packages installed on my system, eight.
They are comerr2g, e2fslibsg, fakeroot, ftplib, libgtk1, libmpeg1,
libpaperg, and procps.
If these packages are doing something wrong, then we have a problem.
So far I have not had any problems with them.
> > What does the ldconfig do, if the symlinks are already there?
>
> RTFM. Also, try it and see. I dare you to take a bo machine, rebuild
> hamm's bash and remove the C postinst which runs ldconfig and then
> install the resultant debs.
I'd love to, but I have no bo machine to spare.
I did R the FM, and it says that
- ldconfig updates the symlinks and the cache.
- ld.so searches LD_LIBRARY_PATH first, then looks in the cache file,
then in the default paths /usr/lib and /lib (where libc6 lives).
- as one might expect from a cache file, it is no problem for it to
be corrupt or nonexistent.
So, what is ldconfig doing that gzip needs?
(I also looked at the source code, in case you care. And I tried
moving libraries around and then running programs that depend on them.
All went fine.)
> (Hint: it tells the dynamic linker that the library is there)
The dynamic linker can see that for itself when it looks for libc.so.6.
If not, there's a bug *somewhere*.
Richard Braakman
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
