On Oct 18, 2007, at 5:27 PM, Bernhard Rosenkraenzer wrote:

> On Tuesday 16 October 2007, Jeff Johnson wrote:
>>> The version on the box that spewed the error messages is 4.4.1, but
>>> the problem occurs only with src.rpms built with current CVS, so I'm
>>> assuming current CVS puts OS and arch markings even into  
>>> src.rpms. Didn't
>>> get to debbuging it yet though...
>>
>> Hmmm, something subtle then. srpm's have had arch/os tags for ages.
>>
>> Lemme see if I can see what the problem is. 4.4.2 is likely similar
>> to 4.4.1.
>
> I've also been able to reproduce this trying to install an rpm5  
> src.rpm using
> rpm 4.4.5, so it's probably something that has been around in rpm4  
> for a long
> time...
>

Hmmm. so what happens with srpm produced by rpm4 on linux is  
installed on FreeBSD?

>> FYI: rpm -qp --yaml foo*.rpm will show all header contents in rather
>> readable form.
>
> That's useful... Here's the diff between --yaml output of 2  
> identical packages
> (rpm4 version diffed against rpm5 version from identical sources  
> and spec) -
> I don't see anything problematic though...:
>

Yah, neither do I. But at least its not a behavior change based on  
srpm content.

Which leaves the implementation(s) and configuration of rpm.

FWIW, there's only 1 (or perhaps 2) places that rpm spews the bad  
arch/os message.

The "traditional" place is a sanity check in rpmtsRun().

The other, more awkward, location is at the top of  
rpmtsAddInstallElement().

I say "awkward" because the sanity check should be done elsewhere, but
rpmtsAddInstallElement() is the first chance rpm gets to see what  
headers the python script
kiddies are attempting to install.

73 de Jeff