Re: Delayed ldconfig execution in postinst step
Eduard Bloch <edi@gmx.de> writes:
> #include <hallo.h>
> * Goswin von Brederlow [Tue, Mar 14 2006, 10:11:43PM]:
>
>> >> 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.
>
> That would require deep integration into dpkg and is hard to track
> (reliably) because package may deliberately have a chain of dependencies
> that lead to the original thing that they need, IMO. Any other opinion
> on that? I would prefer packages requesting a certain "configuration
> state" explicitely if they need it.
Packages already request a certain configuration state by specifying
Depends and such. I see little point in duplicating this information.
>> >> 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".
>
> Again, what is "have a depends"? Watch the dependencies of other
> packages and run the task before configuring them? What if the dependent
> package is installed later, in another dpkg invocation (by apt)?
Package foobar has "Depends: libfoo". There can only be three cases:
1) dpkg -i libfoo; dpkg -i foobar
The ldconfig hook of libfoo is run at the end of dpkg.
2) dpkg -i libfoo foobar
The ldconfig hook is run before configuring foobar. Why? Because
libfoo registers the hook as being run before anything that depends
on libfoo and foobar does depend.
3) apt calls dpkg --delay-hooks -i libfoo; dpkg -i foobar
The ldconfig hook gets registered in the first dpkg run and
executed in the second before foobar. The second dpkg run has to
parse in all pending hooks and handle them as if they had just been
set.
>> 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.
>
> Where is the point? That would be only useful if packages specify a
> certain option for the command, and then rerun each command
> individually. Otherwise, if the error condition is triggered by a file
> state combination, you cannot just go back and execute something
> step-by-step because _all_ package contents are already installed.
There are two cases:
1) dpkg-hook update-bla
All packages use the same simple command to update something. On
failure all packages with this hook should be marked as failed. The
user can then try to configure them one by one but there should be
little point in that. The bug has to be fixed to continue.
2) Each package appends an option
The per package options are e.g. directories to be added to the
font index. On failure dpkg can split all those hook calls up to
see what package caused the failure to occur. The hook scripts have
to be written in a way that they can be rerun selectively after a
failure but that shouldn't be too hard. Optimaly this would pin
point the exact package that causes the failure and properly
configure the rest.
>> 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.
>
> As Frank said, there are cases where you can merge the command execution
> without worrying much about success or failure, and other cases where
> you need to be able to assign the blame.
One could have an option --ignore-error for cases where the result is
truely irelevant. E.g. when it updates some cache just to speed up
operations but also works without.
MfG
Goswin
Reply to: