[arch-dev-public] bluez from testing and pilot-link
Jan de Groot
jan at jgc.homeip.net
Mon Jan 5 13:48:45 EST 2009
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 at koon.fr>:
> > On Sun, Dec 28, 2008 at 12:51, Jan de Groot <jan at 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 at 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 (188.8.131.52-0.1) is newer than extra (1.1.5-2)
> warning: libxcb: local (1.1.93-1) is newer than extra (184.108.40.206-1)
> resolving dependencies...
> looking for inter-conflicts...
> error: failed to prepare transaction (could not satisfy dependencies)
> :: pilot-link: requires bluez-libs>=3.32
> [root at 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?
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.
More information about the arch-dev-public