Re: Bug#579317: calling dh_testdir on mips in the gcc-4.4 build starts 569 processes
On 28/04/2010 01:40, Matthias Klose wrote:
> On 27.04.2010 01:36, Joey Hess wrote:
>> Matthias Klose wrote:
>>> calling dh_testdir in v5 mode on mips in the gcc-4.4 build starts 569
>>> processes
>>
>> The difficulty is that, for each package with a line like:
>>
>> Architecture: $arch $arch $arch
>>
>> If $arch is not "all"/"any", in order to tell if the package is built
>> for the current architecture, debhelper must run 'dpkg-architecture
>> -amipsel -i$arch' for each listed architecture to see if it matches.
>> Because $arch could be "linux-any", it can't just stringwise compare to
>> see if $arch = mipsel.
>>
>> For gcc-4.4, there are 190 such $arches mentioned in its control file.
>> Wow.
>
> I'm not sure how this could be reduced. Just converting these fields to
> any would work for the packaging itself, but would require manual
> actions for ftp maintainance/package removal if biarch builds for some
> architectures are dropped.
>
>> If I memoize that, it'll still need one dpkg-architecture call per
>> unique $arch mentioned in the control file. Which at least will reduce
>> the number to 13 for gcc-4.4. (Plus do stringwise compare first, which
>> will drop it to 12.)
>>
>> If I could assume that any $arch without a dash in it is certianly a
>> real architecture, and not linux-any or some such thing, I could further
>> reduce it to 1 call, for kfreebsd-amd64. Depends how much knowledge
>> about architecure wildcards I want to put in debhelper.
>>
>> If dpkg-architecture had a better interface, debhelper could call it
>> just once. Imagine:
>>
>> dpkg-architecture -amipsel -i"$arch $arch $arch"
>>
>> (Using the new Dpkg::Arch perl module could be a better approach later.)
>
> as a separate question, why does dpkg-architecture needs to call gcc
> -dumpmachine at all?
Maybe because dpkg-architecture can be used on non-build machines and
gcc is not guaranted to be installed there?
--
Jean-Christophe Dubacq
Reply to: