On Feb 24, 2011, at 7:05 PM, Mark Hatle wrote: > 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.
The intent was CPU-VENOR-OS-GNU patterns as being most obvious (and the pesky
-GNU is optional).
But patterns is patterns mostly. As written CPU will be set, VENDOR will
likely be "unknown" and OS will be "linux". IIRC, too lazy to look, the
parser is in lib/rpmc.c: I tried to get sane defaults for 2-tuple and 3-tuple
and 4-tuple forms,
including missing values.
Still
"powerpc" != "ppc"
aliasing is where I draw the line.
>
>>> 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.
>
Yup. nomatch, nomatch, match (from memory, tried to overload RPMRC_OK etc
returns).
> 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.
>
The 1st, not the longest, match will win. The index of the array (which is same
as
line no in /etc/rpm/platform) should be the "score".
>> 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.
>
I get beat up about that code (in rpmAddInstallElement() in lib/depends.c?)
from time to time.
There's no clear reason for warning or error (or existence) of the code afaik.
But that *IS* the very first opportunity where a header is passed into rpmlib
and platform pattern might be checked against package string. There is the
reverse affinity, of package pattern applied to platform string(s) tht
SHOULD be done sometime, but *RE patterns in *.rpm risks accusations of
Incompatibility @rpm5.org!
>> 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)
>
Got the pointer to a *.rpm package? I'll splash some chlorox into the vermouth
and sort out wht the flaw is ...
73 de Jeff
> --Mark
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List rpm-devel@rpm5.org
smime.p7s
Description: S/MIME cryptographic signature
