[Pkg-ia32-libs-maintainers] Building on i386

[Goswin von Brederlow]

Ove Kaaven <ovek at arcticnet.no> writes:

> Goswin von Brederlow skrev:
>> They can not currently be created at build time. The 32bit libraries
>> have to be build on i386 but the ia32-* packages are for amd64 (with
>> the exceptions uploaded so far) and ia64. Building them breaks at
>> several points (correct me when I'm wrong):
>> 
>> - dpkg-gencontrol: amd64/ia64 packages are not added to debian/files
>> - dpkg-genchanges: if added to debian/files the Architecture field
>>                    in changes still comes out i386 [source] causing a
>>                    rejection because the changes file contains
>>                    packages for architectures not listed.
>> - buildd: buildd would most likely be confused by a
>>           libfoo_1.2-3_i386_amd64_ia64.changes file
>> - dak: not sure what DAK will do with multiple uploads for an arch:
>>        libfoo_1.2-3_i386_amd64_ia64.changes from i386
>>        libfoo_1.2-3_amd64.changes from amd64
>>        libfoo_1.2-3_ia64.changes from ia64
>> - wanna-build: uploading libfoo_1.2-3_i386_amd64_ia64.changes confuses
>>                wanna-build into thinking amd64 and ia64 have the
>>                package installed so they would no longer build the
>>                native libs
>
> I don't have that much experience with this, but to my understanding, 
> nothing here is insurmountable.
>
> Both dpkg-gencontrol and dpkg-genchanges will use the environment 
> variable DEB_HOST_ARCH. Just run them once for each architecture with 
> that variable set. Use something like mergechanges (from devscripts) 
> afterwards to manufacture a single .changes file. I believe its name 
> will become libfoo_1.2-3_multi.changes. It should perhaps be renamed 
> back to *_i386.changes, just in case (doubtful it'd make a technical 
> difference, though, stuff is probably looking at the Architecture field 
> in the .changes, not the filename). Anyway, DAK should be able to handle 
> *_multi.changes just fine (otherwise mergechanges wouldn't exist).
>
> With the only remaining real problem being what the buildds think, it's 

If you actually get it tweaked so that it creates *_i386.changes with
the right contents the buildd probably won't notice the extra
archs. I'm guessing but I see no reason why it should check for extra
archs before upload. The upload utility itself only checks the archs
against the debs.

> just a matter of some tweaking or filing bugs on whatever needs fixing 
> to support this, and the path is clear...

Plus each individual maintainer has to add those hacks to their
package. Each one would have to be convinced.

Plus (i forgot before) to do this right the hacks have to be added in
order of dependencies and dpkg-shlibdebs tweaked to pick the
ia32-libfoo package instead of libfoo. While building on i386 both are
32bit and would work just fine. But not later on amd64. So maintainers
have to be convinced in order of depends and can't be approached in
parallel.

Plus many of the packages being frozen so there is no way to get this
into lenny even if the kinks can be circumvented.

Plus multiarch makes this all obsolete so maintainers don't want to
add temporary hacks. If only the binutils maintainer wouldn't keep
blocking that.

The for me insurmountable problem is getting wanna-build to understand
what is going. Tweaking debian/rules has no influence over what
wanna-build does. That problem can't be circumvented from this side.


Note that with split packages they can be replaced one by one with
packages build from the source directly without needing a complete
500MB ia32-libs upload with replaces and depends changes every
time. So even if you go towards adding the hacks then first splitting
ia32-libs up is the way to go.

MfG
        Goswin