[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Delayed ldconfig execution in postinst step



Eduard Bloch <edi@gmx.de> writes:

> #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.

No, into dpkg.

'dpkg -i foo.deb' has to work.

Messing with dpkg is ugly but anything else will not be
optimal. Forking a daemon that waits for dpkg to finish (as is
currently done) is a rather ugly workaround.

>> >> 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.

Only in sofar as to add the --delay-hooks option to the dpkg
invocation to take the most benefit from it. See below.

>> 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.

MfG
        Goswin



Reply to: