The xscreensaver-4.09-r1 wants xpm-3.4k-r1 but xfree 4.3.0 already provides libXpm. The ebuild shouldn't require xpm unless X is missing it. Also, the xpm ebuild overwrites xfree's copy of xpm which seems wrong.
this effects the xscreensaver-4.10 ebuild as well
correct, liquidx i think you have added this dep (?) anyway, the xfree xpm should always be used. Using the ebuild gives problems (search bugzilla). Shall we finally remove the ebuild then, to put a stop to these reoccuring mistakes ? I actually thought this was already done.
yes, I will "move" xpm to xfree
indeed .. well, i guess the xpm dep can go then.
i noticed seemant removed the xpm deps from xscreensaver .. i added virtual/x11 to the deps. it would be kind of pointless to have xscreeensaver without x ;) btw seemant, i thought june was still 2Q2003 ;)
xpm removed from the tree. ${DEITY} help the dev who re-adds it in.
*** Bug 22697 has been marked as a duplicate of this bug. ***
Folks should be advised that unmerging the XPM ebuild deletes the library requiring you to re-emerge xfree. With the latest updates to portage, dep-clean will tell you that the xpm is not depended on by anything indicating that you can unmerge it.
perhaps an ebuild should be made that only lets you unmerge xpm and when it's unmerged it only removes the docs and man files and leaves the libraries/includes so re-emerging xfree isn't required. XFree provides the docs and stuff already, but in a different location than the xpm ebuild, so leaving the libraries would make it seem like it was X's install. this is just a work around but it would solve that problem. Aslong as the libraries and includes are named the same (which I believe they are) whenever they re-emerge xfree they'd be replaced with the original files.
