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.
> 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.
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.
> 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.
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.
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
