On Sat, 2008-12-27 at 22:01 +0100, Andreas Radke wrote:

pilot-link update introduced a changed dependency and this now fails with bluez from testing though new bluez provides bluez-libs

[root@laptop64 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] resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: pilot-link: requires bluez-libs>=3.32

can't pacman handle the provides array well?

-Andy

This is because I added a versioned dependency, while bluez from testing doesn't have a versioned provides. Actually, the bluez in testing is totally incompatible with bluez-libs from extra, so providing bluez-libs is bullshit anyways. I have bluez in my IgnorePkg for a long time already. Bluez in testing is a mess at this moment.

Am Mon, 5 Jan 2009 13:45:11 +0100 schrieb "Geoffroy Carrier" :

On Sun, Dec 28, 2008 at 12:51, Jan de Groot 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

On Mon, Jan 5, 2009 at 12:48 PM, Jan de Groot wrote:

On Mon, 2009-01-05 at 18:38 +0100, Andreas Radke wrote:

...

Am Mon, 5 Jan 2009 13:45:11 +0100 schrieb "Geoffroy Carrier" :

...

On Sun, Dec 28, 2008 at 12:51, Jan de Groot 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.

Agreed. This may still be a pacman issue, though. Let's see if I have this right: bluez-libs: provides nothing bluez: provides bluez-libs pilot-link: depends on bluez-libs>=3.32 So, does bluez just provide "bluez-libs" or is it versioned? Regardless, though, rebuilding pilot-link should fix this particular issue