[Thincrust-devel] unresolved deps on ppc64

[Bryan Kearney]

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