Re: Delayed ldconfig execution in postinst step
Frank Küster <frank@debian.org> writes:
> Eduard Bloch <edi@gmx.de> wrote:
>
>>> dpkg-hook /usr/lib/man/update-manpages - run only once in total
>>> dpkg-hook --on-depends foobar ldconfig - run once before depends of foobar
>>
>> What is a depends? Do you mean dependency or dependents?
>
> I think he means dependents: If package foo depends on library foobar,
> dpkg/apt can unpack and configure-without-ldconfig all packages that
> don't depend on foobar, but it must run ldconfig before any package that
> declares: "Depends: foobar" is configured.
Exactly that sort of thing.
>> Further, I would not depend on package installation operations but
>> instead invent something like "dpkg-hook --execute ldconfig" to run
>> outstanding tasks noted under the name "ldconfig".
>
> This I don't understand...
dpkg would do this automaticaly because the package would have a
depends on the package scheduling the job with "--on-depends".
>> That's all. IMO a matter of few hours to implement and test (in Perl).
>
> *And* it's a matter of setting up a good policy which hooks will be
> implemented/allowed. The problem is that if anything goes wrong when
> executing a postponed command, dpkg has no way to tell which package
> caused the failure, and all packages involved will be marked as
> configured fine, while in fact they may be non-functional.
>
> Therefore it is crucial that only commands
>
> - that cannot sensibly be assumed to fail, und any circumstances
> including f'cked up filesystems,
>
> - or that can safely be assumed to exit with a clear,
> user-understandable error message
>
> can be allowed. Remember, the *user* has to decide what to do, and
> against which package a bug should be filed.
>
> Regards, Frank
We can do better.
1) We already have packages forking of jobs to run in the background
and ignoring their return code. All those job can keep doing so using
the hook mechanism to prevent too much multithreading. E.g. one might
not want to run updatedb together with mandb.
2) dpkg can keep track of all packages that registered a hook. On
failure those packages could be deconfigure or in the case of multiple
packages adding elements to a job (e.g. different font paths) they
could be run disjunct to narrow down the failure.
I also don't think it is too uncommon for a broken package pulling
down all others with the same "hook". If one package messes up its
menu entry the menu system will break. Or a broken font dir can
disrupt X. We already have lots of possibilities for a failure in one
package to influence others. Those cases where a hook would be usefull
already create hard to track interdependencies between packages.
Having dpkg know that a bunch of packages have a common "hook" might
even help detecting and fixing a bug since dpkg can deconfigure
package that are affected by it.
MfG
Goswin
Reply to: