Hi, [upstream CCed]
On Mon, Dec 25, 2006 at 02:19:31PM +0100, Bram Stolk wrote:
> Hi there,
>
>
> I'm currently running bluez-utils version 2.25-1
>
> Upgrading to 3.7-1 gives me the following problem:
>
> I have a server running Debian/testing.
> I want to keep this server completely free from XWindow stuff.
on a clean etch system the installation of bluez-utils brings in the following
packages:
dbus libbluetooth2 libdbus-1-3 libexpat1 libx11-6 libx11-data libxau6 libxdmcp6
x11-common
the only x-related stuff is the x11 client libraries and x11-common, totalling
4MB of diskspace, you won't be able to run an X server with any of those
packages.
>
> However, this server is to act as a bluetooth accesspoint using
> the PAN profile, and the pand deamon.
>
> This works fine with version 2.25-1 of bluez-utils/
>
> With the new version, dbus gets pulled in. Why?
> Isn't libdbus enough?
starting with bluez 3.x most of the functionality has been moved to dbus, which
is used among other things for pinhelper functionalities.
and no, libdbus isn't enough unless I'm missing something, bluez (hcid) needs to
register to the local dbus.
>
> And with dbus, X11 is introduced.
not exactly, a small part of an X11 client is introduced.
>
> This is so ugly...
>
> It should be possible to run pand without the X11 burden.
> It used to be possible in the past, but not anymore.
I'm not sure if it makes any sense to have bluetooth daemons splitted in its own
package.
thanks for your report,
filippo
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Bram,
> > > > the bluez-utils depends on a working D-Bus system bus. It has no
> > > > dependency on X or anything else (besides the Bluetooth library). So if
> > > > it pulls in X related stuff then this is a fault of D-Bus or its package
> > > > and not a problem within the bluez-utils package.
> > >
> > > I'll take this up with the dbus maintainer then.
> > >
> > > I still think that there is no need for X11 client stuff if you
> > > want to run a PAN daemon. Bluetooth communication has nothing to
> > > do with graphics devices. The 2.x version of bluez-utils demonstrated
> > > it can do without.
> >
> > you still don't understand it. BlueZ is _not_ using any X functionality
>
> With all due respect:
>
> I think it is you who does not understand (or not read).
> In my very first mail I wrote:
> "And with dbus, X11 is introduced."
you wrote "Bluetooth communication has nothing to do with graphics ..."
and that is even more true with the bluez-utils-3.x packages since we
dropped the PIN helper which could have introduced a Python-GTK
dependency and was really pulling in unneeded packages. All
communication is done via D-Bus and this makes it language independent
and also graphical desktop independent.
You comparison between how 2.x is working and how 3.x is doing things
simply doesn't work here. Major version are meant to break things or do
things completely different.
> > in its daemons. We never have and we never will be. Period. However we
> > use D-Bus as general communication method and that is a hard dependency
> > now and it won't change in the future. So if you wanna use something
> > that doesn't use D-Bus then stick to the 2.x releases. There was a
> > reason why we changed the major version number.
>
> Ok, fine.
> It's just that when you compare dependencies between 2.x and 3.x, it
> is *not* that the communication method changed: libdbus was a dependency
> for both versions. I do not think that you realized this.
This is not important, because you have hard (mandatory) and soft
(optional) dependency and you simply can't express these within a binary
package. You must look at the source package to see how that works.
Regards
Marcel
_______________________________________________
Pkg-bluetooth-maintainers mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/pkg-bluetooth-maintainers
On Mon, 2006-12-25 at 19:11 +0100, Marcel Holtmann wrote:
> Hi Bram,
>
> > > the bluez-utils depends on a working D-Bus system bus. It has no
> > > dependency on X or anything else (besides the Bluetooth library). So if
> > > it pulls in X related stuff then this is a fault of D-Bus or its package
> > > and not a problem within the bluez-utils package.
> >
> > I'll take this up with the dbus maintainer then.
> >
> > I still think that there is no need for X11 client stuff if you
> > want to run a PAN daemon. Bluetooth communication has nothing to
> > do with graphics devices. The 2.x version of bluez-utils demonstrated
> > it can do without.
>
> you still don't understand it. BlueZ is _not_ using any X functionality
With all due respect:
I think it is you who does not understand (or not read).
In my very first mail I wrote:
"And with dbus, X11 is introduced."
I was, and still am, perfectly aware that the x11 dep comes
from dbus, not from bluez-utils directly. It is literally what
I wrote in my mail. Pleas re-read.
That is why I asked whether libdbus would be enough.
As it turned out that libdbus is not enough, I will take this up
with the 'dbus' people. My guess is that dbus-launch could be
split from the rest of dbus, to avoid bringing in X11 if you want
to do PAN.
> in its daemons. We never have and we never will be. Period. However we
> use D-Bus as general communication method and that is a hard dependency
> now and it won't change in the future. So if you wanna use something
> that doesn't use D-Bus then stick to the 2.x releases. There was a
> reason why we changed the major version number.
Ok, fine.
It's just that when you compare dependencies between 2.x and 3.x, it
is *not* that the communication method changed: libdbus was a dependency
for both versions. I do not think that you realized this.
Thank you for your input,
Bram
> Regards
>
> Marcel
>
>
Hello Marcel,
On Mon, Dec 25, 2006 at 06:14:16PM +0100, Marcel Holtmann wrote:
> > > With the new version, dbus gets pulled in. Why?
> > > Isn't libdbus enough?
> >=20
> > starting with bluez 3.x most of the functionality has been moved to dbu=
s, which
> > is used among other things for pinhelper functionalities.
> > and no, libdbus isn't enough unless I'm missing something, bluez (hcid)=
needs to
> > register to the local dbus.
>=20
> the bluez-utils depends on a working D-Bus system bus. It has no
> dependency on X or anything else (besides the Bluetooth library). So if
> it pulls in X related stuff then this is a fault of D-Bus or its package
> and not a problem within the bluez-utils package.
indeed, my point was that bluez-utils needs the dbus daemon running not just
libdbus (which in turn Recommends the daemon, btw)
>=20
> > > This is so ugly...
> > >=20
> > > It should be possible to run pand without the X11 burden.
> > > It used to be possible in the past, but not anymore.
> >=20
> > I'm not sure if it makes any sense to have bluetooth daemons splitted i=
n its own
> > package.=20
>=20
> No. All of them will be extended with D-Bus functionality anyway. D-Bus
> is the way to go and people fighting it are on a dead end.
agreed
best wishes,
filippo
_______________________________________________
Pkg-bluetooth-maintainers mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/pkg-bluetooth-maintainers
Hi Bram,
> > the bluez-utils depends on a working D-Bus system bus. It has no
> > dependency on X or anything else (besides the Bluetooth library). So if
> > it pulls in X related stuff then this is a fault of D-Bus or its package
> > and not a problem within the bluez-utils package.
>
> I'll take this up with the dbus maintainer then.
>
> I still think that there is no need for X11 client stuff if you
> want to run a PAN daemon. Bluetooth communication has nothing to
> do with graphics devices. The 2.x version of bluez-utils demonstrated
> it can do without.
you still don't understand it. BlueZ is _not_ using any X functionality
in its daemons. We never have and we never will be. Period. However we
use D-Bus as general communication method and that is a hard dependency
now and it won't change in the future. So if you wanna use something
that doesn't use D-Bus then stick to the 2.x releases. There was a
reason why we changed the major version number.
Regards
Marcel
_______________________________________________
Pkg-bluetooth-maintainers mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/pkg-bluetooth-maintainers
On Mon, 2006-12-25 at 18:14 +0100, Marcel Holtmann wrote:
> the bluez-utils depends on a working D-Bus system bus. It has no
> dependency on X or anything else (besides the Bluetooth library). So if
> it pulls in X related stuff then this is a fault of D-Bus or its package
> and not a problem within the bluez-utils package.
I'll take this up with the dbus maintainer then.
I still think that there is no need for X11 client stuff if you
want to run a PAN daemon. Bluetooth communication has nothing to
do with graphics devices. The 2.x version of bluez-utils demonstrated
it can do without.
Bram
Hi Filippo,
> > I'm currently running bluez-utils version 2.25-1
> >
> > Upgrading to 3.7-1 gives me the following problem:
> >
> > I have a server running Debian/testing.
> > I want to keep this server completely free from XWindow stuff.
>
> on a clean etch system the installation of bluez-utils brings in the following
> packages:
>
> dbus libbluetooth2 libdbus-1-3 libexpat1 libx11-6 libx11-data libxau6 libxdmcp6
> x11-common
>
> the only x-related stuff is the x11 client libraries and x11-common, totalling
> 4MB of diskspace, you won't be able to run an X server with any of those
> packages.
>
> >
> > However, this server is to act as a bluetooth accesspoint using
> > the PAN profile, and the pand deamon.
> >
> > This works fine with version 2.25-1 of bluez-utils/
> >
> > With the new version, dbus gets pulled in. Why?
> > Isn't libdbus enough?
>
> starting with bluez 3.x most of the functionality has been moved to dbus, which
> is used among other things for pinhelper functionalities.
> and no, libdbus isn't enough unless I'm missing something, bluez (hcid) needs to
> register to the local dbus.
the bluez-utils depends on a working D-Bus system bus. It has no
dependency on X or anything else (besides the Bluetooth library). So if
it pulls in X related stuff then this is a fault of D-Bus or its package
and not a problem within the bluez-utils package.
> > This is so ugly...
> >
> > It should be possible to run pand without the X11 burden.
> > It used to be possible in the past, but not anymore.
>
> I'm not sure if it makes any sense to have bluetooth daemons splitted in its own
> package.
No. All of them will be extended with D-Bus functionality anyway. D-Bus
is the way to go and people fighting it are on a dead end.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel