On Wed, Mar 15, 2006 at 05:43:38PM +0100, Goswin von Brederlow wrote:
> Nathanael Nerode <neroden@twcny.rr.com> writes:
> > I went through the RC bugs which apply to etch and are older than one year.
> > This is a rather disturbing list, as you would expect from the age of the bugs.
> > In most cases I don't think you can expect the maintainers to deal with these
> > bugs on their own.
> > What are the release managers planning to do about these?
> > First the easy bugs:
> > -------------------
> > Package: libuclibc0 (optional; David Schleef) [uclibc/0.9.27-1 ; =] [add/edit comment]
> > 261725 [ ] libuclibc0 - violates FHS
> > This deserves a long-term exception because the FHS has no reasonable alternative
> > placement, and tools expect the placement used here.
> The multiarch path is different from the cross-tools paths used in
> libuclibc0. The only argument for the multiarch dirs (over cross-tool
> dirs) is that it does not pollute toplevel dirs.
> cross-tools multiarch
> - /lib/$(gcc -dumpmachine)
> /usr/$(gcc -dumpmachine)/lib /usr/lib/$(gcc -dumpmachine)
> /usr/$(gcc -dumpmachine)/include /usr/include/$(gcc -dumpmachine)
> /usr/bin/$(gcc -dumpmachine)-gcc -
> A decision about which to use has to be made NOW if you want any say
> in the matter. Otherwise the multiarch dirs will be added to gcc,
> binutils and glibc any day now.
> libuclibc0 should then just follow their example.
The current multiarch proposal overlooks paths such as
/usr/$(gcc -dumpmachine)/bin/{nm,ld,ar}, which are the paths referenced
internally by the cross-compiler and refer to binaries for the build
architecture used to generate code for the host architecture. These can't
be made to conform to multiarch paths, because there's no spec for
/usr/lib/$(gcc -dumpmachine)/bin or /usr/bin/$(gcc -dumpmachine), and even
if there were it would be the wrong location for native binaries. This
isn't a deficiency in multiarch, it just shows that multiarch isn't a
complete solution for cross-compilers.
So assuming the multiarch-style paths are the preferred solution (because
of, e.g., the ability to create subdirs of /lib), there would still be a
need for /usr/$(gcc -dumpmachine) directories for cross-compilers -- unless
someone "fixes" gcc to be able to use /usr/bin/$(gcc -dumpmachine)-foo
directly. It just wouldn't be the appropriate path for headers and
libraries.
Anyway, I do think that the multiarch-style directories are the right way
forward, but it doesn't make sense to require uclibc to conform to them
before any other packages are doing so. As such, I agree with the idea of
granting uclibc an exception here *if* multiarch doesn't happen for etch;
but in the meantime, I think this bug should be kept on the radar.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature