Nathanael Nerode <[EMAIL PROTECTED]> 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. MfG Goswin PS: A change in the multiarch dir has to be pushed into the FHS multiarch proposal as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]