On Mon, 2009-01-05 at 18:38 +0100, Andreas Radke wrote:
Am Mon, 5 Jan 2009 13:45:11 +0100 schrieb "Geoffroy Carrier" <geoffroy.carrier@koon.fr>:
On Sun, Dec 28, 2008 at 12:51, Jan de Groot <jan@jgc.homeip.net> wrote:
I have bluez in my IgnorePkg for a long time already. Bluez in testing is a mess at this moment. It shouldn't be anymore! Finally started my dev job...
[root@workstation64 andyrtr]# LANG=C pacman -Syu :: Synchronizing package databases... testing is up to date core is up to date extra is up to date community is up to date :: Starting full system upgrade... :: Replace bluez-libs with testing/bluez? [Y/n] warning: libx11: local (1.1.99.2-0.1) is newer than extra (1.1.5-2) warning: libxcb: local (1.1.93-1) is newer than extra (1.1.90.1-1) resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: pilot-link: requires bluez-libs>=3.32 [root@workstation64 andyrtr]# LANG=C pacman -Ss bluez testing/bluez 4.25-1 Libraries and tools for the Bluetooth protocol stack
it's still now satisfied...
I'm not sure if pacman can do this at all when we use version numbers in the (make)depends array. Maybe we should add the required version number in the provides array too? Dan?
-Andy
We should have a rebuilt version of pilot-link (and maybe gnome-pilot) in testing that matches the bluez update. I don't see reason to provide bluez-libs, as any application that linked against bluez-libs is broken when it's run with bluez.