Your message dated Sat, 2 Mar 2019 20:21:03 +0100 with message-id <[email protected]> and subject line Re: Bug#553266: We need more triggers has caused the Debian Bug report #553266, regarding dpkg: We need more triggers to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 553266: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553266 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: dpkg Version: 1.15.3.1 Severity: wishlist Hi, on irc the issue was raised that a package didn't call ldconfig in postinst and I thought to myself: Every library package has a call to ldconfig? That is so stupid. Don't we have dpkg triggers for that sort of thing now? As it turns out dpkg triggers are inadequate for the job because: - file triggers are executed before the file changes, ldconfig must run after - file triggers on directories include subdirs, no need to run ldconfig is /lib/modules/* changes - file triggers can't have wildcards (at least the docs don't mention it) so /usr/lib/*.so.* wont work either. - an explicit trigger would mean every package needs to call dpkg-trigger saving nothing for maintainer scripts, would only reduce the number of ldconfig runs So what we would need here would be a non-recursive directory trigger on /lib and /usr/lib that runs at the end of a dpkg run or possibly before every postinst. [The other (not dpkg related) change to allow a single ldconfig run at the end would be in policy requiring libraries to include the link ldconfig would create. That is currently only a should directive.] MfG Goswin -- System Information: Debian Release: squeeze/sid APT prefers unstable-i386 APT policy: (1001, 'unstable-i386'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29.4-frosties-2 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 7.4-2 The GNU core utilities ii libc6 2.10.1-2 GNU C Library: Shared libraries ii lzma 4.43-14 Compression method of 7z format in dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.7.22.2 Advanced front-end for dpkg -- no debconf information
--- End Message ---
--- Begin Message ---Hi! On Thu, 2009-10-29 at 21:14:00 +0100, Goswin von Brederlow wrote: > Package: dpkg > Version: 1.15.3.1 > Severity: wishlist > on irc the issue was raised that a package didn't call ldconfig in > postinst and I thought to myself: Every library package has a call to > ldconfig? That is so stupid. Don't we have dpkg triggers for that sort > of thing now? > > As it turns out dpkg triggers are inadequate for the job because: > > - file triggers are executed before the file changes, ldconfig must > run after > > - file triggers on directories include subdirs, no need to run > ldconfig is /lib/modules/* changes > > - file triggers can't have wildcards (at least the docs don't mention > it) so /usr/lib/*.so.* wont work either. > > - an explicit trigger would mean every package needs to call > dpkg-trigger saving nothing for maintainer scripts, would only reduce > the number of ldconfig runs > > > So what we would need here would be a non-recursive directory trigger > on /lib and /usr/lib that runs at the end of a dpkg run or possibly > before every postinst. > > [The other (not dpkg related) change to allow a single ldconfig run at > the end would be in policy requiring libraries to include the link > ldconfig would create. That is currently only a should directive.] ldconfig has been triggerized some time ago, so this is clearly inaccurate or not necessary. Closing. Thanks, Guillem
--- End Message ---
