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. Reproducible: Always 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) Actual Results: xlock: blabla cannot find libXpm.so blabla Expected Results: 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? Thomas
closing this as it's outdated anyway.
@ comment #10 , afaicr it was an oversight. It got added without realizing it was already in xfree.
