#include <hallo.h> * Goswin von Brederlow [Wed, Mar 15 2006, 03:17:29PM]: > Eduard Bloch <[EMAIL PROTECTED]> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
