Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#2750 - PATCH: run ldconfig only once

Attached to Project: Pacman
Opened by Indan Zupancic (i3839) - Friday, 20 May 2005, 17:59 GMT
Task Type Feature Request
Category
Status Closed
Assigned To Judd Vinet (judd)
Architecture not specified
Severity Low
Priority Normal
Reported Version 0.7 Wombat
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

See for details http://bbs.archlinux.org/viewtopic.php?p=88721
Patch also at http://nul.nu/~indan/pacman-2.9.5-ldconfig.patch

Currently Pacman runs ldconfig multiple times, or more precisely, numpackages + 1 times.

Another advantage is that the ldconfig is done in the background so the user doesn't have to wait on it.

(application/octet-stream)    ldconfig.patch (2.4 KiB)
This task depends upon

Closed by  Judd Vinet (judd)
Saturday, 11 June 2005, 19:59 GMT
Reason for closing:  Won't fix
Comment by Jan de Groot (JGC) - Friday, 20 May 2005, 18:25 GMT
AFAIK ldconfig is only run once on package installation, otherwise I wouldn't know why I have to run ldconfig for every gst-plugin.
Comment by Indan Zupancic (i3839) - Friday, 20 May 2005, 18:56 GMT
I don't know about that, I used strace to count how often execve ldconfig is done. Your problem may be caused by a not up to date /etc/ld.so.conf, or something like that.

Also ldconfig is run when removing a package, so perhaps by package update ldconfig is run twice currently, or something similar happens. Even if this would be totally unnecessary because it already happens once currently, this patch reduces the total code and does the ldconfig in the background. It may be a bug that it's run multiple times currently.
Comment by Judd Vinet (judd) - Friday, 27 May 2005, 02:04 GMT
The reason I had it running after every package is so scriptlets will always work. For example, if one is installing their first gnome package on a system, it will pull in things like scrollkeeper and gconf. If those packages run their own binaries (which in turn could depend on their own libraries) then it's possible they might not work if the so.cache hasn't been updated.
Comment by Indan Zupancic (i3839) - Friday, 27 May 2005, 02:29 GMT
Ah, the always dreaded install scripts, totally forgot about those.

Interesting, I found this in gnome-common's installscript:

post_install() {
if ! grep '/opt/gnome/lib' etc/ld.so.conf >/dev/null 2>&1; then
echo "/opt/gnome/lib" >> etc/ld.so.conf
sbin/ldconfig -r .
fi
}

Same for the post_install.

It seems that either those can be removed, or that they can be mandated. Removing them and just letting Pacman do it is probably safest. So just close this bug, rerunning ldconfig doesn't take that long if the file cache isn't pushed away by some big package, and then the download time is much longer anyway, making it insignificant (or a luxery problem).

Though I would take the part of the patch which moves the ldconfig call into it's own function, avoiding code duplication.

Loading...