* Ng Oon-Ee <ngoonee@gmail.com> [28.09.2010 21:07]:
On Tue, 2010-09-28 at 20:19 +0200, uli.armbruster@googlemail.com wrote:
* Ionuț Bîru <ibiru@archlinux.org> [28.09.2010 17:41]:
On 09/28/2010 06:39 PM, Samir wrote:
I have a question about Best Practices or... a clean way of handeling these types of scenarios...
I've seen this come up with several packages....
If I install mplayer and x264 from pacman, but then pull x264-git from aur, and install that.
x264 conflicts with x264-git which makes sense.. but then mplayer suddenly is broken because libx264.so.104.
Basically mplayer isn't aware that x264-git (which naturally conflicts with the x264 package).
Now, to be fair.. mplayer probably should have been linked against libx264.so rather then libx264.so.104 (-git package provides a libx264.so.105).
When I was on a purely from source distro, I'd just force a rebuild of mplayer and its dependencies...and that would fixed the issue.
from a user perspective: what's the solution to these types of situations. (creating a symlink to the .so file doesn't count).
from a packager perspective: Should we do anything in particular to take these sorts of situations into account and try to avoid some of these problems.
is instructing the user to pull the abs source the solution?
-- csgeek
use abs to recompile mplayer against x264-git and put mplayer into IgnorePkg in the /etc/pacman.conf This way pacman will spit out a warning as soon as there's an update available for mplayer, but doesn't actually update it. You simply have to wait for this message, build mplayer again by yourself with the newer PKGBUILD from abs and you're good.
Or use bauerbill and set mplayer to automatically compile from abs if there's an update =) Right! I used bauerbill for a few days, but seems like I forgot about this functionality ;-)