Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Steve Langasek <vorlon@debian.org> writes:
> On Sun, Aug 09, 2009 at 11:18:27PM +0200, Goswin von Brederlow wrote:
>> > 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.
>
> $ zgrep usr/lib/i486-linux-gnu dists/unstable/Contents-amd64.gz |grep -c wine
> 921
> $
>
> These are biarch packages, using the i486 path on amd64.
>
> This is not multiarch at all.
No. That is the extra doubly ugly wine hack that uses the precompiled
i386 build tree in the source to generate the amd64 package. Don't
hold that against ia32-libs-tools.
Under ia32-apt-get the i386 wine package would be installed, not the
even uglier than ia32-libs wine hack. With ia32-apt-get that package
could actualy be removed from the archive making things cleaner.
>> If you think that is wrong then that is a bug in wine. Nothing to do
>> with ia32-libs-tools.
>
> If a package that ships files in the multiarch paths is installed using
> ia32-libs-tools, where will the resulting biarch package's files be located?
> Will they not be in the multiarch paths?
They will be wherever you tell me to put them.
>> > -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.
>
> That has nothing to do with being -dev packages.
>
>> They need a multiarch capable extended toolchain, meaning libtool,
>> pkg-config,
>
> You have not demonstrated that this is dependent on the passing of a stable
> release cycle. If you had any sense at all, you would be working out a
> design for what *does* need to happen here instead of wasting everyone's
> time with ia32-libs-tools.
>
>> automake, autoconf.
>
> Unlikely that anything needs to change here, but not relevant to -dev
> packages anyway.
>
>> They need to work with the existing biarch -dev packages or have to
>> replace them.
>
> Which, again, does not block on having an intervening release cycle.
>
>> Last I heart multiarchifying -dev packages was not planed for Stage 1
>> of the multiarch proposal. Has that changed?
>
> No. Who said that stage 2 has to wait until after squeeze is out?
Ok, then I stand corrected.
My point was that all of multiarch will not be done by the end of
August and I think that still stands.
MfG
Goswin
Reply to: