xfree <4.3.0 does not contain libXpm.so. for all of us running an older xfree
it's impossible to get xpm-support.
if one (like me) masks 4.3.0* out and updates to the (in portage) xpm-4.3k-r2
the library get's deinstalled and all programs linked against it ... well.
Steps to Reproduce:
pre-requisite: your xfree is <4.3.0*
1. emerge -u xpm
2. start a pgm with xpm-support (e.g. xlock)
xlock: blabla cannot find libXpm.so blabla
i cannot expect xlock (in the example) to start properly but there should be an
easy way of re-installing the old working xpm-package.
If this is the case, we should probably do the same thing with xpm and >=xfree-4.3
that we do with xft on >=xfree-4.3.0-r2, just have both provide a virtual
and block each other. Any other thoughts?
sounds good: blocking would prevent the innocent from loosing their libXpm.so
(without any warning) -- and that's a good thing ;)
Well ... can we have "media-libs/xpm-3.4k-r1.ebuild" back in portage till this
get's fixed "the clean way"(tm)?
hi again -- this is _our_ chance for getting an easy "bug-closed" point ;)
*please* put it back in portage. At the moment it's impossible to get xpm-support
if you are not using xfree 4.3.x.
Thanks for bugging me, there's a lot going on lately. =) If it's not done in a week, bug me again, but I hope to look at this shortly.
Foser, could you comment on this? Seemant said you might have something to say.
But do you have any reason we shouldn't have xpm for people with xfree<4.3 ? Seemant was also interested in using it again for xfree 4.4.
sorry, sort of forgot to answer this.
We have xpm in xfree, because there is no significant difference between the seperate pack and the one in xfree (see #1446 ). As far as i know building xpm is on by default in any xfree ebuild (any default xfree config really). I haven't checked, but i couldn't find any mentions in the changelogs/patches about disabling it (this is spyderous area really).
The only way one could lose xpm is to have the seperate package installed over the xfree one and then removed later on, so the Xpm lib would be removed. A simple 'qpkg -l xfree | grep Xpm' should prove this theory. If that is the case, well then it's unfortunate for these users, but for the better of all other users it would be wise to leave Xpm out.
It might make sense to move the xpm build into the xfree-4.2 ebuild if you think it's a good idea to keep it out of the tree as a whole and 4.2 indeed lacks this. I haven't verified yet.
i actually don't think 4.2 lacks it, bug #1446 refers to 4.2.x ebuilds. The reporters should be able to verify this (see #7 ).
it's exacly as foser says: 4.2.x includes xpm ("epm -ql xfree | grep Xpm" like
suggested in #7). it was lost by installing xpm and removing (well updating in
fact to the virtual and cleaning the package) it later on.
i'd agree that under that circumstances it's best for the majority of the users
to leave the virtual as it is and not to add the old version again to portage.
just out of curiosity: what was the reason for the separate xpm-package then?
Wasn't xpm included in xfree <4.2.x or was it just an oversight?
closing this as it's outdated anyway.
@ comment #10 , afaicr it was an oversight. It got added without realizing it was already in xfree.