Re: Delayed ldconfig execution in postinst step
#include <hallo.h>
* Goswin von Brederlow [Wed, Mar 15 2006, 03:17:29PM]:
> 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.
Tracking dependencies (in a reliable way) would move the whole thing
above the dpkg layer, that is what I wanted to avoid.
> >> 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.
Also means moving the thing into apt.
> 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.
Great. But needs interaction with apt which I do not like.
> >> 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.
ACK.
> >> 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.
ACK.
Eduard.
Reply to: