RPM Community Forums

Mailing List Message of <rpm-devel>

Re: %post-script prerequisites

From: Jeff Johnson <n3npq@mac.com>
Date: Wed 24 Sep 2008 - 19:56:35 CEST
Message-id: <D576A10F-09D7-466E-8F52-0D19CBC80F76@mac.com>

On Sep 24, 2008, at 1:44 PM, Alexey Tourbin wrote:

>>> Think about this again: package foo has program /usr/bin/update-foo,
>>> which is invoked in %post-script of the package.  The program is
>>> linked
>>> with e.g. libglib-2.0.so.0(GLIB_2.18), and we have the dependency
>>> "Requires: libglib-2.0.so.0(GLIB_2.18)".  However, this is merely
>>> "Requires".  To run /usr/bin/update-foo in the %post script  
>>> reliably,
>>> that must be "Requires(post)".  Or otherwise there's a possibility
>>> that,
>>> despite topological reordering, glib2 gets installed or upgraded  
>>> after
>>> foo, and so the %post scriptlet fails miserably.
>>>
>>> So, there's a general problem: if you both package a program and run
>>> it in the %post-script (in the very same package), then bare  
>>> Requires
>>> are not enough: some of them (namely, which are used by the program)
>>> should also become Requires(post).
>>
>> Mebbe.
>>
>> IMHO, there are several flaws in the above.
>>
>> The fundamental flaw (imho) is trying to add secondary
>> dependencies to a package node in the dependency graph.
>>
>> If the chain A -> B -> C is necessary for running /usr/bin/update-foo
>> in a script, then A should have
>> 	Requires: B
>> and B should have
>> 	Requires: C
>> and the dependency graph should be assembled dynamically,
>> not added statically to A.
>
> +# The solution is: 1) to detect all packaged programs (and files),  
> recursively,
> +# which are used in %post-script; and 2) to find prerequisites for  
> such files
> +# and programs (which are not provided by the package itself), and  
> add them to
> +# Requires(post) dependencies.  Also, we want to ensure that 3)  
> the list of
> +# Requires(post) additional dependencies is only a subset of  
> original Requires.
>

Note that all I've seen is the comments, I have no clue other than that.

And we differ largely in "recursively", specifically whether the  
missing "B -> C"
edge should be attached to the A (as you are attempting) or the B (as  
I'm suggesting)
node.

I don't think we differ on "reliability", if a secondary B->C edge is  
missing,
then yes, rpm cannot order correctly.

> Note that there are three steps, and the last step is explicitly
> about not adding secondary dependencies.  So, for the package foo,
> it goes like this:
> 1) We see that the packaged program /usr/bin/update-foo is invoked
> in %post script (in the very same package!).
> 2) We run find-requires for /usr/bin/update-foo, and get some
> dependences, which are candidates for Requires(post); they are
> libglib-2.0.so(GLIB_2.18) and others (but no secondary dependencies
> anyway).
> 3) Requires(post) candidates are intersected with the "Requires"
> of the package.  Sine /usr/bin/update-foo is packaged, there must
> be "Requires: libglib-2.0.so(GLIB_2.18)", too.  This step is basically
> required only because of some glitches in dependency generators (i.e.
> some generators work best when they process the whole list of specific
> files, to make some folding).
>

OK, "glitches" are everywhere, in scripts, in packages, in compilers  
and kernels, everywhere.

Redundancy can help overcome glitches, yes. But redundancy will  
always result in bloatery.
All depends on what the important metric is.

>> Also your claim
>>
>>> To run /usr/bin/update-foo in the %post script reliably,
>>> that must be "Requires(post)".
>>
>> is false. The "(post) marker limits the context where a
>> dependency applies, and does not improve reliability at all.
>
> To run /usr/bin/foo in the %post-script reliably, there must be
> "Requires(post): libglib-2.0.so(GLIB_2.18)" dependency.  "Reliably"
> means that, unless we have this "Requires(post)" dependency on recent
> glib2 version, there's a possibility that glib2 gets installed/ 
> upgraded
> *after* foo, which is too late for its %post-sciprt).  What's false in
> this claim?
>
> Anyway, perhaps I should do some rewording in my initial description
> of the problem.  In ALT Linux mailing list (in Russian), there seems
> to be some misunderstanding (or maybe a lack of thereof), too.

Lots of misunderstandings wrto Requires(post): and PreReq:.

But I still question whether "(post)" is fixing anything at all. Try  
and see,
push a reproducer to me if you'ld like comments.

73 de Jeff
Received on Wed Sep 24 19:57:12 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.