Bug 212421 - request to remove "Requires: bluez-gnome" from bluez-utils
request to remove "Requires: bluez-gnome" from bluez-utils
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: bluez-utils (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Woodhouse
:
: 212825 248440 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-26 14:44 EDT by Peter E. Popovich
Modified: 2011-06-13 10:24 EDT (History)
11 users (show)

See Also:
Fixed In Version: 1.0-0.34.beta8.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-12 16:04:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter E. Popovich 2006-10-26 14:44:13 EDT
Description of problem:
bluez-utils is useful, even on text-mode and headless systems.  The Fedora
package for bluez-utils explicitly requires bluez-gnome though.  This means that
a 374K rpm of CLI utilities and daemons depends on 13M of gnome and xorg rpms.

Pretty sure the fix is to remove "Requires: bluez-gnome" from bluez-utils.

Version-Release number of selected component (if applicable):
3.7-2

How reproducible:
Inherent to current bluez-utils release.

Steps to Reproduce:
1. rpm -qp --requires bluez-utils-3.7-2.i386.rpm | grep bluez
  
Actual results:
>>rpm -qp --requires bluez-utils-3.7-2.i386.rpm | grep bluez
bluez-gnome  
bluez-libs >= 3.7
config(bluez-utils) = 3.7-2

Expected results:
>>rpm -qp --requires bluez-utils-3.7-2.i386.rpm | grep bluez
bluez-libs >= 3.7
config(bluez-utils) = 3.7-2

Additional info:
This isn't a new problem.  Before the recent update, bluez-utils used to depend
on bluez-pin.  With the change though, it's very clear that bluez-gnome is a
gnome UI app, and as noted previously, bluez-utils is functional without it.
Comment 1 David Woodhouse 2007-07-21 05:55:50 EDT
hcid now uses dbus unconditionally for fetching a PIN. I don't see any
alternative to requiring bluez-gnome. Marcel?
Comment 2 Marcel Holtmann 2007-07-21 06:25:25 EDT
Actually you can either use bluez-gnome of kdebluetooth or whatever passkey
agent you wanna use. I think that a suggests is more appropriate than a requires.

The BlueZ passkey agent interface is designed to serve all kinds of purposes and
is fully generic. The bluetooth-applet from bluez-gnome is only one way to get
achieve a proper PIN input.
Comment 3 David Woodhouse 2007-07-21 06:41:23 EDT
We can't do 'suggests'. We could have a virtual 'bluez-pinhelper' which is
provided by any passkey agent, so that you can use kdebluetooth or some other
possibility. 
Comment 4 David Woodhouse 2007-07-21 06:45:48 EDT
*** Bug 248440 has been marked as a duplicate of this bug. ***
Comment 5 Marcel Holtmann 2007-07-21 06:55:49 EDT
You better call it bluez-passkey or bluez-passkey-agent. The term PIN helper
refers to the old system and is no longer in use.

However besides the passkey agent we also have the authorization agent. So we
might wanna use a more generic term. I would propose bluetooth-ui or something
like that.

Do we have a virtual package bluetooth so you can simply do a yum install
bluetooth and the basic components are installed.
Comment 6 David Woodhouse 2007-07-21 08:15:04 EDT
*** Bug 212825 has been marked as a duplicate of this bug. ***
Comment 7 David Woodhouse 2007-07-21 08:17:00 EDT
Should we be shipping the passkey agent and authorisation agent which are part
of the bluez-utils package? If so, in what form?

No, we don't have a virtual 'bluetooth' package. We install the bluetooth
packages by default.
Comment 8 Marcel Holtmann 2007-07-21 08:28:48 EDT
A system can be used without any passkey agents. For some use cases you don't
need a PIN code at all. The authorization agent is not asked if you for example
use SetTrusted() to fully trust a remote device. The whole idea is to have a
fully modular system and make the UI easy replaceable.

So no passkey agent and no authorization agent should be part or required by
bluez-utils. However when you install a GNOME desktop you should make sure that
bluez-gnome is also installed.
Comment 9 Peter Lemenkov 2007-07-21 08:56:56 EDT
(In reply to comment #1)
> hcid now uses dbus unconditionally for fetching a PIN. I don't see any
> alternative to requiring bluez-gnome. Marcel?

Some hardware don't need any passkeys. For example Apple Wireles Mighty Mouse.
All I need to use it under Linux may be done in three steps:

* install bluez-libs and bluez-utils
* get its ID by hciotool scan
* add to /etc/rc.d/rc.local new string: hidd -c ID

That's all. No need to Gnome cra... stuff.

Comment 10 Marcel Holtmann 2007-07-21 09:40:49 EDT
Your point is correct, but your example is wrong. The Apple Wireless Mouse
indeed requests a PIN code. It is 0000.
Comment 11 Bastien Nocera 2007-09-20 05:51:56 EDT
bluez-gnome is installed in the default installation. Maybe we shouldn't force
bluez-utils to require it, and let the package/system installers deal with that
problem by themselves. The problem isn't so uncommon for other applications...
Comment 12 Douglas E. Warner 2007-09-20 07:37:12 EDT
kdebluetooth now supports the DBUS method for retreiving/setting pins, so 
maybe there's some virtual Provides that both bluez-gnome and kdebluetooth can 
provide?
Comment 13 Bastien Nocera 2007-10-04 08:34:15 EDT
Gilboa, are you ok with a virtual provides? What should we call it?
Comment 14 Gilboa Davara 2007-10-05 19:12:15 EDT
Yes.
How about provides: dbus-pin-handler?

BTW, do you plan on getting this change in before F8-release?

- Gilboa
Comment 15 Bastien Nocera 2007-10-06 09:51:20 EDT
(In reply to comment #14)
> Yes.
> How about provides: dbus-pin-handler?

Yep. I used dbus-bluez-pin-helper (helper is what BlueZ uses in in config, and
I'd rather add "bluez" in there to avoid possible conflicts) in
bluez-utils-3.20-2, and bluez-gnome-0.14-7

Please close the bug once you've done the kdebluetooth build.
Comment 16 Gilboa Davara 2007-10-07 18:18:00 EDT
A new kdebluetooth build is out. (With provides: dbus-bluez-pin-helper).

Closing BZ.
Comment 17 Fedora Update System 2007-10-08 11:02:08 EDT
kdebluetooth-1.0-0.34.beta8.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kdebluetooth'
Comment 18 Fedora Update System 2007-10-12 16:04:18 EDT
kdebluetooth-1.0-0.34.beta8.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 19 tz 2010-10-23 19:49:51 EDT
I would like to maybe reopen this.  I work on embedded systems and really, really don't want to include Gnome (gtk, the whole X, etc).  The problem is not so much bluez-gnome is a dependency, but it in turn is dependent on the whole graphical desktop.

The project is for a wifi-to-bluetooth (and maybe i2c sensor) gateway so I could use any smartphone via a web server.  I will need pins, but those can be preset.

This is like requiring the gnome-desktop if you want to use USB.

The PIN problem is fixed by any of several simple python scripts or programs using dbus.

The problem is it becomes impossible to use RPM or YUM to install things to my system if it is going to insist on including hundreds of megabytes of things I will never use, and don't want.
Comment 20 tz 2010-10-23 20:01:57 EDT
I should add that I would be willing to work on and contribute an alternate means of getting PIN numbers.  Ultimately I will need something for my web interface project, and the test-agent works and I have already modified it.  If I create a bluez-scriptable-pin package or something similar, would it help?

Note You need to log in before you can comment on or make changes to this bug.