On 2/16/11 12:21 PM, Jeff Johnson wrote:
>
> On Feb 16, 2011, at 12:35 PM, Mark Hatle wrote:
>
>>>
>>> I'll dig the rest of the fix out over the next few days.
>>
>> So what I was working on was a situation where the automatic dep solver
>> wasn't
>> finding packages. It turns out that there were some "compatible packages"
>> problems going on. The patch located at:
>>
>> http://git.pokylinux.org/cgit.cgi/poky/tree/meta/recipes-devtools/rpm/rpm/rpm-platform.patch
>>
>> fixes the issue for Poky.
>>
>> Majority of it simply disables some hacked that were "RPM_VENDOR_WINDRIVER",
>> around the "isCompatible". These might have to come back in the future --
>> or an
>> alternative to fix the multilib issues WR had (vs poky).. but I'm going to
>> try
>> to avoid them in the future.
>>
>
> Passing SYSCONFIGDIR as (possibly) an rpm macro "%{_etcrpm}" and then using
> rpmExpand() instead of xstrdup() might flush some of the details from the
> code. Dunno if you can get the rpm macro passed from AutoFu -> ... -> C
> defines
> straightforwardly.
hadn't considered that, but ya as long as _etcrpm is always defined somewhere
that should work, and reduce some of the complexity.
>> The remainder of the patch fixes a problem I found with the sysinfo
>> loading...
>> and then the real issue I was having.
>>
>> I needed a way to pass the path to the platform file while I was coming up
>> with
>> an install solution. This also cleaned up the platform file path in the same
>> was as sysinfo loading worked.
>>
>> I do note that under the OPENPKG vendor, there was previously a value of
>> __platform defined for a similar purpose, but the name I choose
>> "_rpmrc_platform_path" seems to more closely match the sysinfo path.
>>
>
> I do wish Poky and Mandriva and Openpkg could converge to a common solution
> for /etc/rpm/platform.
>
> Per Oyvind's libcpuinfo is essentially re-writing platform based on whether
> its elf32 or elf64, where scoring differs between.
>
> Poky (and likely OpenPKG I've forgot) need precise control for
> cross-platform images.
>
> If up to me, I'd add some macro magic madness to stop with the path
> rewrites, and then add an immediate %{load:...} where macros are
> already expanded in paths.
>
> The whole issue is bootstrapping: evaluating macros wile initializing macros
> requires a certain discipline and methodology.
We're not using PREMACROFILES.. I forgot to mention, in that patch I had to call
the PREMACROFILES loader so that the early default values (of things like
_etcrpm) were defined.. calling it with a NULL accomplished it when
PREMACROFILES was not defined.
> Also please note that PREMACROFILES just won't ever solve the bootstrapping
> issue. I just hven't gotten to pushing the attempts under
> #ifdef RPM_VENDOR_MANDRIVA
> on HEAD and on rpm-5_4 (I believe I ripped out PREMACROS in rpm-5_3)
>
> I tried with --predefine and --define years ago. Dinna work then, will
> not work now.
I'm using --predefine to specify the location of the sysinfo directory and the
platform file. Works great, I just didn't know --predefine even existed before
this exercise!
> The whole issue is bootstrapping ... and it gets really nasty/ugly
> when bindings like rpm-python -- which also call rpmReadConfig() --
> are considered.
Ya, luckily I don't have to do that -- yet -- but I suspect with the
Zypper/sat-solver work I'm going to have to figure out how to pull that in..
(the platform file also needs to be wired into the sat-solver/zypper so it can
also determine which packages are available/allowed)... We're working on that
for Poky...
--Mark
> hth
>
> 73 de Jeff
>> Any comments?
>>
>> --Mark
>
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
