Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Steve Langasek <vorlon@debian.org> writes:
> On Sun, Aug 09, 2009 at 05:43:37PM +0200, Goswin von Brederlow wrote:
>> - Moving libraries from /usr/lib/ to /usr/lib/$(DEB_HOST_GNU_TYPE) in
>> individual packages.
>
>> If this is done (like experimental wine has just done) then
>> ia32-libs-tools can stop moving files from /usr/lib to
>> /usr/lib32.
>
> Oh great, so experimental wine is now also using paths intended for
> multiarch in biarch packages.
>
> This is an FHS violation, and should be treated as a serious bug.
No, it is using multiarch paths in native packages. The way packages
are supposed to do for multiarch. Maybe it is a bit ahead of the curve
but it is exactly doing what multiarch expects it to do.
If you think that is wrong then that is a bug in wine. Nothing to do
with ia32-libs-tools.
>> Once Stage1 of multiarch (as per the Ubuntu proposal) is completed,
>> and that is a release goal for squeeze, ia32-libs-tools will only
>> have to handle packages that didn't multiarchify in time for squeeze
>> (and there will certainly be some left) and -dev and -dbg packages that
>> need Stage2 of multiarch (which requires a stable release cycle).
>
> -dev packages don't require a stable release cycle before conversion to
> multiarch.
They do if they need an architecture specific depenency, think perl,
python, ocaml, apache. They need a multiarch capable extended
toolchain, meaning libtool, pkg-config, automake, autoconf. They need
to work with the existing biarch -dev packages or have to replace
them.
Last I heart multiarchifying -dev packages was not planed for Stage 1
of the multiarch proposal. Has that changed?
Maybe you misunderstood me. I don't mean libfoo-dev_1.2-3_amd64.deb on
amd64. That probably/hopefully works smoothly with Stage 1. I ment
libfoo-dev_1.2-3_i386.deb. Use case would be for example to compile
the latest wine on amd64 without having to need a full i386 build
chroot.
MfG
Goswin
Reply to: