Re: Delayed ldconfig execution in postinst step
#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.
> >> 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)?
> 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.
> 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.
> 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.
In my opinion, having too touchy postinst script is already a problem.
And IMO we have some meta tasks that are not critical for the correct
package installation but make the upgrades less stable.
I believe to remember package upgrades where things like doc-base
failed, and I always have the question: who t.f. cares about doc-base?
If that command breaks after all package contents are installed, ok, I
can live with that. It just should not break in the middle of the
installation.
Eduard.
--
<Tolimar> ETESTS: Wir sollten dir vielleicht fairerwaise sagen, dass es sich
bei "vi" und "vim" um Text-Editoren handelt, und "vigor" ist ein "vi"
mit der nervigen Büroklammer aus *würg* Word.
<somnium> was ist Word??
<Tolimar> somnium: Etwas, dass nicht gut genug ist, um längere Texte zu
schreiben. Sonst hies es doch "paragraph" oder wenigstens "sentence".
Reply to: