Re: migration exception for mhap
On 30/07/16 08:54, Afif Elghraoui wrote:
> Hello,
>
> I'm sorry that I've been away from my email for a while. I was also
> hoping for some discussion of Emilio's point.
>
> على الإثنين 25 تـمـوز 2016 09:19، كتب Emilio Pozuelo Monfort:
>> Hi,
>>
>> On 25/07/16 11:13, Jonathan Wiltshire wrote:
>>> On 2016-07-24 23:11, Afif Elghraoui wrote:
>>>
>>>>> For performance reasons britney only tests installability on amd64 and
>>>>> i386 (hence the message), otherwise the list would be much longer.
>>>>>
>>>>> A package cannot migrate if it is not installable on the test
>>>>> architectures.
>>>>>
>>>>
>>>> For the purposes of mhap, it is a package for scientific research and
>>>> would probably not be usable on i386 even if it could be installed
>>>> there. It requires more powerful processors than anything that is i386
>>>> that I am aware of (besides am64 CPUs posing as such, but the package
>>>> works on x32 anyway).
>>>
>>> Maybe you want "arch:any-amd64 x32" then?
>>
>> I'm not sure about that. mhap is arch:all. It just happens to be uninstallable
>> on some architectures because one of its dependencies isn't available
>> everywhere. Whenever that dependency gets support for those architectures, then
>> mhap will be installable.
>>
>> This isn't different to sspace, circlator, pbalign, console-setup-freebsd,
>> python-pbcore, python-pbgenomicconsensus... to name a few.
>>
>> Maybe we should change our policy here or fix some stuff (including how britney
>> handles arch:all packages), but we should carefully think about it and then be
>> consistent about it.
>>
>
> For the people who hold the view that, if a package of
> architecture-independent files is not installable on i386, it should be
> duplicated for each of the architectures on which it will be
> installable, has this opinion taken the approval of the ftpmasters? I
> don't think they would be in favor of the idea of wasting space on the
> archive for this reason.
>
> I completely agree with Emilio, as well as Ansgar who made this point
> before[1].
I have added a force-hint.
Cheers,
Emilio
Reply to: