[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Replacing ldconfig maintscripts with declarative methods

On 2015-08-23 17:01, Niels Thykier wrote:
> 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

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 Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Attachment: signature.asc
Description: Digital signature

Reply to: