bluez requires dbus-bluez-pin-helper which pulls in one of the following desktop environment packages:
# repoquery --whatprovides dbus-bluez-pin-helper gnome-bluetooth-0:2.27.1-4.fc11.x86_64 bluez-gnome-0:1.8-16.fc11.x86_64 kdebluetooth-1:0.3-3.fc11.x86_64
I think @base should be limited to non-gui packages.
Perhaps a bluez-desktop package to pull in dbus-bluez-pin-helper?
On a server:
Installing: bluez x86_64 4.32-8.fc11 rawhide 464 k Installing for dependencies: kde-filesystem noarch 4-24.fc11 rawhide 22 k kde-settings noarch 4.2-4.20090225svn.fc11 rawhide 36 k kde-settings-kdm noarch 4.2-4.20090225svn.fc11 rawhide 24 k kdebase-runtime x86_64 4.2.1-1.fc11 rawhide 6.7 M kdebase-runtime-libs x86_64 4.2.1-1.fc11 rawhide 1.4 M kdebase-workspace x86_64 4.2.1-4.fc11 rawhide 13 M kdebase-workspace-libs x86_64 4.2.1-4.fc11 rawhide 744 k kdebluetooth x86_64 1:0.3-3.fc11 rawhide 169 k kdelibs x86_64 6:4.2.1-4.fc11 rawhide 14 M kdelibs-common x86_64 6:4.2.1-4.fc11 rawhide 364 k kdepimlibs x86_64 4.2.1-4.fc11 rawhide 2.0 M kio_sysinfo x86_64 20090216-3.fc11 rawhide 356 k ksysguardd x86_64 4.2.1-4.fc11 rawhide 74 k solar-kde-theme noarch 0.1.17-3.fc11 rawhide 290 k
Transaction Summary ======================================================================== Install 15 Package(s) Update 0 Package(s) Remove 0 Package(s)
Total download size: 39 M
Funny that kdebluetooth wins over bluez-gnome. I thought shortest wins, or is this an epoch thing?
On Tue, 2009-03-17 at 14:45 -0600, Orion Poplawski wrote:
bluez requires dbus-bluez-pin-helper which pulls in one of the following desktop environment packages:
# repoquery --whatprovides dbus-bluez-pin-helper gnome-bluetooth-0:2.27.1-4.fc11.x86_64 bluez-gnome-0:1.8-16.fc11.x86_64 kdebluetooth-1:0.3-3.fc11.x86_64
I think @base should be limited to non-gui packages.
Perhaps a bluez-desktop package to pull in dbus-bluez-pin-helper?
<snip>
It's not a "desktop" thing, it's a "make Bluetooth do something" thing. If you can't pair (or at least connect and trust), you can't use the device, simple as that.
Write a command-line version of it, and I'm sure we'll find a place for it.
Funny that kdebluetooth wins over bluez-gnome. I thought shortest wins, or is this an epoch thing?
Cheers
Kevin Kofler (kevin.kofler@chello.at) said:
Orion Poplawski wrote:
Funny that kdebluetooth wins over bluez-gnome. I thought shortest wins, or is this an epoch thing?
AFAIK, bluez-gnome is obsoleted by gnome-bluetooth, which has a longer name than kdebluetooth.
Then bluez-gnome either needs to be blocked, or not built (if it's a subpackage.)
Bill
Bill Nottingham wrote:
Kevin Kofler (kevin.kofler@chello.at) said:
Orion Poplawski wrote:
Funny that kdebluetooth wins over bluez-gnome. I thought shortest wins, or is this an epoch thing?
AFAIK, bluez-gnome is obsoleted by gnome-bluetooth, which has a longer name than kdebluetooth.
are you saying that packages that provide the same functionality are chosen to install by which has the shorter name?
phil
On Wed, Mar 18, 2009 at 6:49 PM, psmith johnsmithdoe14@googlemail.com wrote:
Bill Nottingham wrote:
Kevin Kofler (kevin.kofler@chello.at) said:
Orion Poplawski wrote:
Funny that kdebluetooth wins over bluez-gnome. I thought shortest wins, or is this an epoch thing?
AFAIK, bluez-gnome is obsoleted by gnome-bluetooth, which has a longer name than kdebluetooth.
are you saying that packages that provide the same functionality are chosen to install by which has the shorter name?
yes that's how it work.
drago01 wrote:
On Wed, Mar 18, 2009 at 6:49 PM, psmith johnsmithdoe14@googlemail.com wrote:
Bill Nottingham wrote:
Kevin Kofler (kevin.kofler@chello.at) said:
Orion Poplawski wrote:
Funny that kdebluetooth wins over bluez-gnome. �I thought shortest wins, or is this an epoch thing?
AFAIK, bluez-gnome is obsoleted by gnome-bluetooth, which has a longer name than kdebluetooth.
are you saying that packages that provide the same functionality are chosen to install by which has the shorter name?
yes that's how it work.
wow, that just seems so archaic!
On Thursday 19 March 2009 14:17:44 psmith wrote:
drago01 wrote:
On Wed, Mar 18, 2009 at 6:49 PM, psmith johnsmithdoe14@googlemail.com
wrote: ...
are you saying that packages that provide the same functionality are chosen to install by which has the shorter name?
yes that's how it work.
wow, that just seems so archaic!
You might want to pester Seth for a --dwim flag for yum.
On Thu, 2009-03-19 at 14:17 +0000, psmith wrote:
are you saying that packages that provide the same functionality are chosen to install by which has the shorter name?
yes that's how it work.
wow, that just seems so archaic!
There are actually a number of other factors that are considered and given weight, shortest name is just one of those factors/weights that are used to decide which package to pick.
If you have better suggestions, I'm sure the yum devs would love to hear about it.
On Thu, 19 Mar 2009, Jesse Keating wrote:
On Thu, 2009-03-19 at 14:17 +0000, psmith wrote:
are you saying that packages that provide the same functionality are chosen to install by which has the shorter name?
yes that's how it work.
wow, that just seems so archaic!
There are actually a number of other factors that are considered and given weight, shortest name is just one of those factors/weights that are used to decide which package to pick.
If you have better suggestions, I'm sure the yum devs would love to hear about it.
When a providing pkg is looked up for a requirement, if we know what is requesting it then that pkg is factored into the assessment. look at _compare_providers() in depsolve.py in yum for the gruesome details.
-sv
-
Bastien Nocera -
Bill Crawford -
Bill Nottingham -
drago01 -
Jesse Keating -
jon doe -
Kevin Kofler -
Orion Poplawski -
Seth Vidal