Based on earlyer bugreports, the libwww ebuild got a DEPEND=" !dev-libs/9libs ". Since 9libs installs its header files in /usr/include/9libs, this shouldn't be needed any longer.
<snip> Add block for !dev-libs/9libs since that causes a compile failure since 9libs installs a custom libc.h that breaks things. </snip> Hmmm, well... not sure if this is solved, but that block is wrong anyway, since there's no mutual block in libwww. This seems virtually dead upstream anyway (last release 4 1/2 years ago) and lacks a maintainer, probably best punted from portage altogether.
(In reply to comment #1) > there's no mutual block in libwww. Err, 9libs doesn't block libwww is what I meant... :/
If the two don't collide anymore, then just remove the block. If 9libs works fine and there are no bugs open, I'm not going to punt it :)
Let's punt this, there's another collision (Bug 137932) and the whole thing seems to do more harm than good.
As I mentioned, all collisions that resulted of libc.h being in /usr/include/ are resolved. Concerning (Bug 137932), I don't think punting packages is the default procedure to follow on manpage conflicts. Of course there was no update on 9libs for 4 1/2 years, it's a Plan9 library environment and won't change until Bell Labs release the next edition. If it's just the lack of a maintainer, I would jump in.
(In reply to comment #4) > Let's punt this, there's another collision (Bug 137932) and the whole thing > seems to do more harm than good. > Patience (In reply to comment #5) > As I mentioned, all collisions that resulted of libc.h being in /usr/include/ > are resolved. Concerning (Bug 137932), I don't think punting packages is the > default procedure to follow on manpage conflicts. > > Of course there was no update on 9libs for 4 1/2 years, it's a Plan9 library > environment and won't change until Bell Labs release the next edition. > > If it's just the lack of a maintainer, I would jump in. > If you want to keep it in the tree, some work regarding the collisions is necessary. I'm reluctant at this point to punt it just because the bugs aren't that old; there is plenty of other stuff that is far worse off. If you are interested in fixing the collisions, I am interested in fixing the package as opposed to removing it.
No file-collisions here - net-libs/libwww blocks dev-libs/9libs for no reason; text-markup please remove this.
All done (well, as soon as my crappy internet connection convinces CVS that something is happening...).