[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools



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.

> 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?

> > -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?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org


Reply to: