[Thincrust-devel] unresolved deps on ppc64

David Huff dhuff at redhat.com
Tue Nov 11 14:43:16 UTC 2008


Bryan Kearney wrote:
> David Huff wrote:
>> Bryan Kearney wrote:
>>> David Huff wrote:
>>>> Bryan Kearney wrote:
>>>>> David Huff wrote:
>>>>>> David Huff wrote:
>>>>>>> David Huff wrote:
>>>>>>>> Problem with appliance-tools
>>>>>>>>
>>>>>>>> Appliance-tools relays on qemu-img to convert the disk format of 
>>>>>>>> an appliance, however it looks like qemu is not included on 
>>>>>>>> ppc64.  Since applaince-tools is noarch I don't think that I 
>>>>>>>> can  define the valid arches in the spec file with ExclusiveArch.
>>>>>>>>
>>>>>>>> I would like to keep the package noarch if passable any 
>>>>>>>> suggestions?
>>>>>>>>
>>>>>>>> -D
>>>>>>>>
>>>>>>> https://admin.fedoraproject.org/updates/F9/FEDORA-2008-8868
>>>>>>
>>>>>>
>>>>>> What I am going to do is take out the "requires: qemu-img" in the 
>>>>>> spec and add logic to appliance-cretor that checks for the 
>>>>>> qemu-img rpm when you used the --format option.  If its not 
>>>>>> installed it will exit with a error which also states that qemu is 
>>>>>> not available on ppc64.
>>>>>
>>>>> So.. the tools you build on a arch-specific (livecd-tools, qemu). 
>>>>> Why not be arch specific in the appliance-tools?
>>>>>
>>>>> -- bk
>>>>>
>>>>
>>>> Since we already have an noarch RPM in F-9 and F-10 we would have to 
>>>> deprecate it and introduce the arch specific RPM's.  My thinking is 
>>>> that this would just be easier.  However I am open to suggestions here.
>>>
>>> Lets test how painful of a migation process this is.
>>>
>>
>> I did a quick test on F-10 box with no issues. It looks like as long 
>> as your using a relatively newer version of yum, someone one on 
>> #fedora-admin mentioned f8 or >, there is no upgrade issues.  I am not 
>> sure if any other issues could arise form such a change.  I am also 
>> trying to remember why we switched to a noarch in the first place.
>>
>> Can anyone think of any cons to moving appliance-tools to an arch 
>> specific rpm?
> 
> Not I, it seems like the right way to solve the issue, and to provide 
> internally consistent tooling.
> 
> -- bk
> 

So we may need to move to arch specific rpms in the future, however I 
have work around for noq, see below. If we do move to an arch specific 
RPM I would like to do it in a new release like 004 for F-11, not as an 
update to an already release rpm.

The work around is including "ExclusiveArch: %{ix86} x86_64 ppc alpha 
sparc armv4l noarch" in the spec, which matches qemu.

This keeps the rpm noarch, however when the trees/repos are composed the 
package is only included in the trees specified in the ExclusiveArch 
field in the srpm.

Both new builds as of yesterday include the ExclusiveArch definition and 
will only be included in the repos specified above.

-D




More information about the Thincrust-devel mailing list