doesnt seem to make too much sense ... /usr/include/bglibs/ would make a lot more sense
bglib packages are built to have everything under directory. the /usr/lib/bglibs/{bin,lib,include} structure predates me, but none of the original developers that put it into the tree are still around. How's /usr/bglibs/{bin,lib,include}?
god no, /usr/ is def off limits :P if the upstream bglibs guys cant be taught to learn how to package properly, do we have to suffer ? :) i dont know much about bglibs, i just noticed while reviewing Bug 88852
bglibs is basically a set of extra libs to libc. Large parts of it can be used without glibc (yes, another partial libc replacement...). It also builds as a pure static lib (there is no shared version). Older packages may support the split variant: $prefix/{include,lib}/bglibs but upstream strongly discourages this, and doesn't really support it for new packages that use bglibs (anything since 2004-06 basically).
care to take bug 88852 then since i dont really want to deal with this ? :) it's a 'bglibs' package
well, /usr ist what dietlibc used.... but i agree, it's not a clean solution
Created attachment 58208 [details] bglibs-1.019-r1.ebuild how about this then.... - all header files are stored in /usr/include/bglibs - all libraries are stored in /usr/lib/bglibs - symlinks for backwards compatibility in /usr/lib/bglibs/{include,lib} are created fixes also - use toolchain-funcs instead of gcc eclass - uncompressed html doc (what about the latex stuff?) - set year to 2005
diet libc is a 'libc' replacement ... that's why it is installed under /usr/diet ... you can build a whole toolchain against it with a 'diet' target just like a 'i686-pc-linux-gnu' target
in cvs now.
