Re: Replacing ldconfig maintscripts with declarative methods
Niels Thykier writes ("Replacing ldconfig maintscripts with declarative
methods"):
> 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.
I think this is a good idea.
> * The major concern I have, is that "activate"-triggers are done for
>- unpack (is this ok?)
It had better be ! (Ie I think it is OK.)
> * Performance-wise we would see up to 5 calls to ldconfig instead of
>1-2 per "dpkg run" (that processes triggers).
OTOH the reduced number of maintscript invocations might well outweigh
that.
Thanks,
Ian.
Re: Replacing ldconfig maintscripts with declarative methods
On 2015-08-25 15:12, Ian Jackson wrote:
> Niels Thykier writes ("Replacing ldconfig maintscripts with declarative
> methods"):
>> 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.
>
> I think this is a good idea.
>
Thanks. :)
Also thanks for the feedback - It is not the easiest subject in Debian
packaging, so I am glad to have an extra set of eyes on it. :)
>> * The major concern I have, is that "activate"-triggers are done for
>>- unpack (is this ok?)
>
> It had better be ! (Ie I think it is OK.)
>
Indeed, I had a hard time finding a case where that could not already
have happen by "accident" (at least before ldconfig started using
triggers internally).
>
>> * Performance-wise we would see up to 5 calls to ldconfig instead of
>>1-2 per "dpkg run" (that processes triggers).
>
> OTOH the reduced number of maintscript invocations might well outweigh
> that.
>
> Thanks,
> Ian.
>
One could hope. :)
I will wait a couple of days more for feedback before starting on this.
Thanks,
~Niels
signature.asc
Description: OpenPGP digital signature
Re: Replacing ldconfig maintscripts with declarative methods
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 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Replacing ldconfig maintscripts with declarative methods
On 2015-08-29 23:52, Aurelien Jarno wrote: >[...] > >> * 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. > Excellent! :) > 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. Ok. I was not aware that we had this requirement. However, the current setup does not enforce it AFAICT. It seems that triggers are the very last thing to happen! """ $ aptitude -R install mscgen [...] Unpacking libgd3:amd64 (2.1.1-4) ... Selecting previously unselected package mscgen. Preparing to unpack .../mscgen_0.20-4_amd64.deb ... Unpacking mscgen (0.20-4) ... Setting up libexpat1:amd64 (2.1.0-7) ... [...] Setting up mscgen (0.20-4) ... Processing triggers for libc-bin (2.19-19) ... $ """ However, if we move to explicit triggers, then dpkg will now trigger ldconfig just before running postinst scripts: """ $ apt-get install ../mscgen_0.20-4+ddebtest1+triggers1_amd64.deb [...] Selecting previously unselected package mscgen. Preparing to unpack .../mscgen_0.20-4+ddebtest1+triggers1_amd64.deb ... Unpacking mscgen (0.20-4+ddebtest1+triggers1) ... *Processing triggers for libc-bin (2.19-19) ...* Setting up libexpat1:amd64 (2.1.0-7) ... [...] Setting up mscgen (0.20-4+ddebtest1+triggers1) ... Processing triggers for libc-bin (2.19-19) ... """ As long as one package have the explicit trigger, dpkg it will now trigger it correctly. In my particular test case, I added it to mscgen (despite it not being a library). >> [...] > > 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. > Excellent. :) >> 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 > Ok, currently this is guarded by a: if dpkg --compare-versions "$libc_bin_version" lt "2.18-2"; then AFAICT, what will happen is: * libc6 preinst upgrade will disable ldconfig * dpkg will unpack stuff incl. libc-bin - This will restore ldconfig * dpkg will run the trigger (unpack) - This will run ldconfig * dpkg will configure stuff as usual This seems to be similar to the old approach, except the trigger will now be run before configuring packages. Thanks, ~Niels signature.asc Description: OpenPGP digital signature
Re: Replacing ldconfig maintscripts with declarative methods
Hi, As of debhelper/9.20151004, dh_makeshlibs is now using triggers rather than maintainer scripts to invoke ldconfig. * Lintian in untable + testing is already aware of this * Lintian has /not yet/ been backported. Lintian from backports still (incorrectly) reports this an issue. Please do not hesitate to let me know if you experience any issues with this change. Thanks, ~Niels
Re: Replacing ldconfig maintscripts with declarative methods
Hi! On Mon, 2015-10-05 at 16:14:38 +, Niels Thykier wrote: > As of debhelper/9.20151004, dh_makeshlibs is now using triggers rather > than maintainer scripts to invoke ldconfig. > > * Lintian in untable + testing is already aware of this > * Lintian has /not yet/ been backported. Lintian from backports still >(incorrectly) reports this an issue. Wonderful! Thanks for this Niels. Regards, Guillem
