On 2015-08-23 17:01, Niels Thykier wrote: > Hi, Hi, > Currently, all Debian libraries (is required to) have a call ldconfig in > postrm and postinst. I would like to replace that with a declarative > method somehow. There are a couple of reasons for this: > > * Packages without postinst scripts do not need to be "configured" > explicitly (because dpkg can see there is nothing to do for them). > This provides two improvements: > > - It means there are fewer "constrains" for dpkg and APT to solve > to compute an ordering for install/upgrades[1]. > > - dpkg can also safely break dependency cycles at packages without > postinst scripts, since it knows that the package will not need > anything from its dependencies to be configured. > > => I know that there are people trying to remove dependency cycles > all together. This solution does /not/ intend replace that > goal. It will only improve the chance that dpkg can safely > handle a given cycle. > > * There are also some "minor" optimisations like: > > - We can remove thousands of postrm+postinst scripts. > - We can remove the "hack" in libc-bin to replace ldconfig calls with > a no-await trigger (see below) That's sound quite interesting indeed. > The current state: > > * Packages have the scripts to call ldconfig > > * To reduce install time, libc-bin replaced /sbin/ldconfig with a shell > script. This detects whether it should immediately call (the real) > ldconfig OR (if called from a maintscript) should call dpkg-trigger. > > - ldconfig calls dpkg-trigger with --no-await, so it will not cause > trigger cycles. > > > A possible solution is to replace these scripts with an > "activate-no-await" trigger (again, no-await to avoid trigger cycles). > I would need libc-bin to promote its trigger to part of its API for this > to work. Also, I need some help understanding some corner cases: > > * The major concern I have, is that "activate"-triggers are done for > - unpack (is this ok?) > - configure (ok) > - remove (ok, assuming it is post-removal) > - purge (should not be an issue) > - deconfigure (would be a no-op, since the library is not actually > removed at this point) As a general rule it should not be a problem to call ldconfig at any moment. Therefore I don't see a problem to call ldconfig in the above steps. What we should ensure is that if package A depends on package B, ldconfig is called *before* starting the postinst of package A to fill the cache with info from package B. If it is not done, it should only have a performance impact on the native architecture (ld.so looks up for the default paths if the info is not in the cache), but it will just break with foreign architecture, or non standard library paths declared in /etc/ld.so.conf. > * Performance-wise we would see up to 5 calls to ldconfig instead of > 1-2 per "dpkg run" (that processes triggers). > - Being no-await, dpkg have freedom to "re-order" and "merge" all > the activations. > - In the long run, it might make sense to get support for only > activating triggers at certain "states". Though I doubt the > performance overhead will be the greatest issue On the performance side, ldconfig has a cache mechanism, which makes calls to ldconfig very very cheap if nothing has changed. So I don't think it would be a problem. > Feedback is very welcome. If this idea is uncontroversial, I move > forward to update debhelper+lintian as well as file bugs against policy. We currently have ugly hacks removing ldconfig.real in case it will break the system in the preinst script. If we go for this solution, we should not forget to change that part also. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: Digital signature