Re: How to build a 32-bit package in Debian?
On Wed, Jan 26, 2011 at 06:46:33PM +0100, Goswin von Brederlow wrote:
> Adam Borowski <kilobyte@angband.pl> writes:
> > Aren't ia32-libs on their way out, together with rest of the bi-arch stuff?
>
> Since sarge, yes. Nothing is as permanent as a quick temporary hack.
With no multiarch on horizon, there wasn't anything to replace them with.
Since the libraries there are all prominent and maintained, it's plausible
transitioning them will be done quickly.
Especially if done in the toolchain rather than individual packages.
> >> or the revised apt-ma-emu. Saddly the squeeze freeze hit before
> >> apt-ma-emu was ready for upload so it won't be in squeeze.
> >
> > At a glance, it appears to do the same thing as xapt except that it doesn't
> > require manual selection of packages to install and can do upgrades
> > automatically. Which are good things, thanks for telling us about this
> > tool. It would be nice to have it in experimental.
>
> It might appear so at a glance and you probably looked at an earlier
> version. The differences are quite large though in practice. It tries to
> emulate what multiarch will do as much as possible and will phase out
> its meddling as packages actualy become truely multiarch.
Is apt-ma-emu 0.3 supposed to be working already?
It's not in the archive yet, so I wonder whether we should:
a) report bugs to you, or
b) refrain from using it for now
Problem one:
It seemed to work when installing thing needed for binutils/gcc, but now any
attempt to install a cross package results in:
dpkg: error processing
/var/cache/apt/archives/libpng12-0-armel-cross_1.2.44-1~0.3_amd64.deb
(--unpack): no package information in `/var/lib/dpkg/tmp.ci/control'
configured to not write apport reports
dpkg: error processing
/var/cache/apt/archives/zlib1g-dev-armel-cross_1%3a1.2.3.4.dfsg-3~0.3_amd64.deb
(--unpack): no package information in `/var/lib/dpkg/tmp.ci/control'
configured to not write apport reports
Problem two:
Cross packages seem to conflict with native ones, even though all are either
libfoo1 or libfoo-dev. I did not investigate where the problem comes from,
mostly due to 1., it worked ok with xapt.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Reply to: