RPM Community Forums

Mailing List Message of <rpm-devel>

Re: ordering issues

From: Per Řyvind Karlsen <pkarlsen@rpm5.org>
Date: Thu 13 Jan 2011 - 13:12:14 CET
Message-ID: <AANLkTiko8jLsVBU36_UnKTwPqKmQ4neR9YsCFGpqPbkH@mail.gmail.com>
2011/1/13 Jeff Johnson <n3npq@mac.com>:
>
> On Jan 13, 2011, at 5:29 AM, Per Řyvind Karlsen wrote:
>
>>
>> But given that Requires(post) indicates that it's required at
>> scriptlet time, shouldn't rpm consider this as coretuils>pam?
>>
>
> There is no "scriptlet time".
>
> There are
>        1) needed for installing
>        2) required while installed
>        3) needed for erasing
> relations used for ordering.
>
> These relations split into 1+2 and 2+3 "times" (or sets) so its possible to
> split a dependency loop with markers like Requires(post):.
Yes, but Requires(post) suggests that something is required during %post, right?
Shouldn't rpm then sort Requires(post): before Requires:?

>
> But the usage case is too narrow to be generally effective, and
> its just as easy to arrange for the packaging to do the right ting.
>
>> This seems to be the behaviour we've had and based our packaging on in
>> cooker with rpm <= 4.6..
>>
>
> (aside)
> Claim anything you wish about rpm behavior: what's in rpm-5.3 has
> hardly been changed in a decade. Its kinda ironic to hear the
> noise about rpm broke this and broke that!
Well, I dunno at which time it might've changed, but with rpm 4.6
Requires(pre,prein,post,postun): were sorted to be ordered before
Requires:, which is something the packaging in cooker has been heavily
relying on..
>
>> I'll be going through various other loops with %_depedendency_whitout
>> now and try play my way through it..
>>
>
> Adding %_dependency_whiteout is expedient: works and you will have a list
> of what relations need to be fixed when you are done.
>
> I'd also start listing the LOOP's somehow. Invisible LOOP's will never
> ever be fixed.
--
Regards,
Per Řyvind
Received on Thu Jan 13 13:12:33 2011
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.