[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#703436: Multi-arch builds uses wrong UDEB_EXCLUDE



On Wed, Mar 20, 2013 at 10:30:55AM +0200, Robert Spencer wrote:
>On 19/03/2013 18:09, Steve McIntyre wrote:
>>
>>Ish. In fact, there's a deeper bug here - the udeb include/exclude
>>code is actually worse than you think. At the moment, we get away with
>>things only because the amd64 and i386 files provided with debian-cd
>>are identical. The code here just doesn't work properly with
>>multi-arch builds as there is no way to specify different files in
>>CONF.sh for the different arches. Equally, d-i only looks for its
>>include and exclude lists in one place on an install CD regardless of
>>architecture so there's currently no way of passing different config
>>for the different arches *anyway*.
>>
>>As you might guess, this piece of the code hasn't been played with for
>>a while!
>>
>>I'm thinking a better way to handle this would be to pick up on the
>>data files for all arches rather than just the first one, and merge
>>them. What do you think?
>
>I'm not sure that I'm following you. Do you mean something like
>default_netinst_udeb_include with the following in:
>
>netcfg
>ethdetect

Not quite, no. I'm thinking of keeping the per-arch include/exclude
files and merging at build time.

>And then if it's alpha include "fdisk-udeb" or amd64 or i386 include
>"pcmciautils-udeb".
>
>Alternatively if it's just the .disk/udeb_include and
>.disk/udeb_exclude files you don't want duplicates in, then we can
>filter them out while maintaining the order (I'm assuming the order
>is important).

Filtering is fine, ordering doesn't matter at all AFAICS. The issue
that worries me more is the fact that different arches have different
lists that should go here, maybe with bad consequences if they're
wrong. Maybe I should be tweaking things in d-i too to add per-arch
control.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews


Reply to: