On 2/24/11 3:39 PM, Jeff Johnson wrote:
>
> On Feb 24, 2011, at 4:18 PM, Mark Hatle wrote:
>
>> I'm getting a message:
>>
>> warning: package rpm-5.4.0-r13.ppc603e is intended for a ppc603e-pc-linux-gnu
>> platform
>>
>> In my /etc/rpm/platform file I have:
>>
>> qemuppc-poky-linux-gnu
>
> This one is a string.
So would:
qemuppc-poky-linux-gnu
qemuppc
ppc603e
powerpc
noarch
any
all
Be correct, or should I wild card these or? Sorry, I'm a bit confused
(obviously) as to the format and expectations.
>> ppc603e-poky-linux-gnu
>> powerpc-poky-linux-gnu
>> noarch-poky-linux-gnu
>> any-poky-linux-gnu
>> all-poky-linux-gnu
>>
>
> these are patterns (but strings are subsets of patterns).
>
>> the package was generated using --target ppc603e-poky-linux-gnu, but the
>> platform that got embedded into package is: ppc603e-pc-linux-gnu
>>
>> I'm looking at the rpmPlatformScore function and I don't really understand
>> how
>> it's supposed to work. But I would have expected that ppc603e-pc-linux-gnu
>> to
>> be compatible with ppc603e-poky-linux-gnu in my platform file.
>>
>
> The "score" should end up being the line no. of the 1st pattern that
> matches from /etc/rpm/platform. So arrange your patterns in priority order.
>
> Meanwhile the whole basis for "scoring" was based on trying to
> track
> i386 -> i486 -> i586 -> i686
> kernel/openssl optimized packages (which there are almost none),
> and to prevent n00by lusers from attempting (by returning a negative score)
> to install ppc on i386.
>
> Are those RPM training wheels still needed a decade later?
>
>> Any suggestions as to what might be going wrong and how to correct it? (and
>> yes, if I put ppc603e-pc-linux-gnu into the platform file, the warning goes
>> away!)
>>
>
> I never use anything but a single COU-VENDOR-OS line in /etc/rpm/platform
> (which is why the functionality never really gets tested by me).
>
> Adding --miredebug is the 1st step towards debugging. You should see
> a "1" (RPMMIRE_STRCMP) for the first line in /etc/rpm/platform, and "2"
> (RPMMIRE_REGEX) for the remaining lines when the patterns are created.
<-- mireRegexec(0x10017348, 0x1002e808[20]) rc -1 mode 1 "ppc603e-pc-linux-gnu"
<-- mireRegexec(0x100173a0, 0x1002e808[20]) rc -1 mode 2 "ppc603e-pc-linux-gnu"
<-- mireRegexec(0x100173f8, 0x1002e808[20]) rc 0 mode 2 "ppc603e-pc-linux-gnu"
I assume this is the debug.. it didn't match the first line, so it went to the
second, didn't match.. then the third and hit with the rc 0.
A different package with the arch of qemuppc:
<-- mireRegexec(0x10017348, 0x1002fd00[20]) rc -1 mode 1 "qemuppc-pc-linux-gnu"
<-- mireRegexec(0x100173a0, 0x1002fd00[20]) rc 0 mode 2 "qemuppc-pc-linux-gnu"
Again same assumption, only it didn't hit the qemuppc-poky-linux-gnu, but did
the following line.
> You should also be able to read the results of all pattern matching.
>
> But this code breaks every 6-9 months regular as clockwork largely
> because everyone wants RPMTAG_ARCH compatibility and that code
> was removed in rpm-4.4.7 and I'm NOT going back there to trapping
> SIGILL to tell a ppc64 with faulty flash is running (because of setarch)
> in ppc32 mode. Life's too short for SIGILL ick.
Ya, I disabled all of the SIGILL PPC stuff.. it's completely the wrong way to do
it.. (I understand the legacy reasons why it was done, but for me it'll never
trigger.)
>> Note: it says it's a warning but it's actually an error during install -- it
>> silently prevents you from performing the install.
>>
>
> Change the error to a warning if you wish. I personally see no reason why RPM
> needs to protect lusers from themselves to the extent that has always
> been implemented in RPM.
Thats the issue. It looks like a warning, but RPM -is- protecting the user by
not installing.. the behavior I want is for RPM to warn (if it's concerned) but
do the install.
> The world of emulation and cross-compilation was NOT what was anticipated
> when RPM started to use uname(2) to determine arch in 1997.
>
> And the flaws in RPM (and the right answer, to use /proc/cpuinfo attributes
> instead)
> were pointed out by Alan Cox in 1998.
>
> And so it goes ... but I'll dig out the issue for you if you need. I'll
> need the package and /etc/rpm/platform contents and the --target
> CLI option (2 or 3 you've already given me) in order to
> reproduce.
Sure... The current /etc/rpm/platform I have is:
qemuppc-poky-linux-gnu
qemuppc
ppc603e
powerpc
noarch
any
all
The command line for rpmbuild is:
rpmbuild --nodeps --short-circuit
--target ${pkgarch}-poky-linux-gnu
--buildroot ${pkgd}
--define '_topdir ${workdir}' --define '_rpmdir ${pkgwritedir}'
--define '_build_name_fmt %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm'
--define '_use_internal_dependency_generator 0'
--define '__find_requires ${outdepends}'
--define '__find_provides ${outprovides}'
--define '_unpackaged_files_terminate_build 0'
--define 'debug_package %{nil}'
-bb ${outspecfile}
(If you are wondering debug_packages are generated as part of the spec file --
so auto generation is disabled... the find_requires/provides is switched to an
external script that produces results based on rpmdeps and poky internals)
--Mark
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
