Sorry, i haven't read carefully the problem posted. Regards
On 7/7/08, Jeff Johnson <[EMAIL PROTECTED]> wrote: > > > On Jul 7, 2008, at 5:45 AM, devzero2000 wrote: > > I agree with Jeff, but if you want a naive solution then, in my-rpm SPEC >> >> Require(pre): vendor-provided >> Require(post): my-post >> >> > Careful ... > > There are (at least 3) attached meanings to "pre" used in *.rpm packaging. > > 1) PreReq: <-> Requires: > The tsort originally implemented in rpm was broken and needed > a PreReq: hint (implemented as the RPMSENSE_PREREQ flag, now obsolete) > in order to function correctly. > > All Requires: are fully honored, as if all dependency carried > RPMSENSE_PREREQ, > and so the PreReq: hint is no longer needed or useful. > > 2) Requires(pre): > This is a context marker that narrows the scope of tsort relations. The > context > marker is in the flag RPMSENSE_SCRIPT_PRE, and was originally added to > break a nasty glibc <-> bash dependency loop in the "inner circle" of > dependency hell. > > 3) The mathematical term "prerequsite" defining how a topological sort > algorithm functions. > > All 3 of the above are very different, and should not be confused. > > Meanwhile, AFAICT the desire is to retrofit an additional tsort relation > into > a vendor package as in 3) above. > > Since the vendor package (presumably) cannot be changed and is missing > information, then > Requires(pre) will not help. In fact, a wider, rather than a narrower, > scope is what is needed afaict, > so 2) likely won't work at all. > > And 1) won't help either, since PreReq: and Requires: are synonyms, all > Requires: > relations have the property that was originally marked with > RPMSENSE_PREREQ. > > But I still dunno why a prerequsite relation needs to be retrofitted into a > vendor package ... > > 73 de Jeff > ______________________________________________________________________ > RPM Package Manager http://rpm5.org > Developer Communication List rpm-devel@rpm5.org >
