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