Robert Millan <[EMAIL PROTECTED]> writes:
> On Mon, Jan 24, 2005 at 08:25:35AM +0100, Goswin von Brederlow wrote:
>> >
>> > Build-Depends: bin86 [cpu: i386]
>>
>> What does Build-Depends: bin86 [cpu: i386, mips] mean? All i386 cpus
>> and linux-mips? All i386 cpus and all mips cpus?
>
> All i386 cpus and all mips cpus.
>
>> What about [cpu: i386, system: linux]? Is that linux-i386 or any i386
>> cpu or any linux system?
>
> That syntax is not (yet?) supported by my patch. In any case I'd prefer:
>
> [cpu: i386 ...] [system: linux ...]
>
> which is easier to parse. However, note the example is equivalent to [i386]
> currently.
>
>> Beware that unless you get this into sarge it can't be used before
>> etch is released, which means somewhere around 2008-2010.
>>
>> Also is it allowed to say "Cpu: mips, mipsel" for mips/mipsel specific
>> but endian independent files, e.g. kernel docs and patch for
>> mips/mipsel.
>>
>> Last but not least have you looked at DAK and figured out what needs
>> patching there to support this?
>
> These three questions have basicaly the same answer: my patch doesn't
> modify the way dpkg interacts with DAK. dpkg-genchanges uses Cpu/System
> logic to determine wether we can build a package, but when generating
> DEBIAN/control it will add an "Architecture" field set to DEB_HOST_ARCH.
>
> So, DAK can work ignorant of this feature. This means the combination you
> describe won't work any better than currently. (i.e., if you want to avoid
> data duplication, you'll have to set it to "all". If you want to have it for
> mips and mipsel, you'll have to accept data duplication).
Then we can just keep using type-handling for this.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
