Re: Antique RC bugs (many about licensing)
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.
MfG
Goswin
PS: A change in the multiarch dir has to be pushed into the FHS
multiarch proposal as well.
Reply to: