Hi,
I'm packaging bluez-4.4 right now and just wanted to gather opinions about the
package naming (it might be good if distributions could agree on consistent
naming of packages).
So how is everybody going to name the packages? The "old" ones for bluez-3.x
were easy:
- either bluez-libs or libbluetooth2 for the libs
- bluez-utils for the hcid and hciconfig and related stuff
- bluez-audio for the audio stuff (packaged separately because of
the dependencies
- bluez-cups for the cups backend
>From a first glance, I'd just keep the package-naming as is, but since it is a
major version update anyway, if we want to change it, now might be a good time
;-)
Opinions, anyone?
--
Stefan Seyfried
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
Hi Marcel (and everybody else still listening),
Marcel Holtmann wrote:
> if we go always polling the D-Bus and try to re-connect it is bad, too.
> The solution is to make sure that D-Bus is always running and will never
> die. Everything else is just wrong and will break.
Yes, this was obviously meant as a joke.
This is what I have packaged for now:
- DBus activation for bluetoothd (actually runs the init script)
- udev events run a helper script /lib/udev/bluetooth.sh which basically
consists of:
#!/bin/sh
[ x"$ACTION" != xadd ] && exit 0
touch /var/run/bluetooth-adapter-present
/bin/dbus-send --system --type=method_call \
--print-reply --reply-timeout=1000 \
--dest=org.bluez / org.bluez.hello
- a "bluetooth-coldplug" init script that checks for the existence of the
bluetooth-adapter-present file and runs the "normal" init script (This could
all be put into the normal init script, but I had reasons for splitting
it up).
So the coldplug case will be handled by the second init script, but still the
bluetoothd will only be started if an adapter is present.
Maybe this is kind of a solution until we get DBus started early enough to
make the problem go away.
Another thought: what prevents us from making bluetoothd exit as soon as all
adapters are unplugged? Is it useful for anything without hardware present
(can you alter settings etc)?
Thanks (and have fun in Portland ;)
Stefan
--
Stefan Seyfried
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
Hi Stefan,
> > we had the discussion for Fedora and we want to start it via udev,
> > however then we need D-Bus before udev runs and that is not an option
> > right now. So the current solution is to just do it via init.d, but in
> > the future we want udev.
>
> What about the old hack that I had back in the old days that would let hcid
> wait until D-Bus came up? ;-) One problem with init.d is that the daemon is
> running, even if there is no device plugged in...
if we go always polling the D-Bus and try to re-connect it is bad, too.
The solution is to make sure that D-Bus is always running and will never
die. Everything else is just wrong and will break.
Regards
Marcel
Marcel Holtmann wrote:
>> I had that old udev rule hack that would call the init script at adapter
>> plugin, but that's ugly and racy (because it typically starts before DBus is
>> started).
>>
>> Any innovative ideas?
>
> we had the discussion for Fedora and we want to start it via udev,
> however then we need D-Bus before udev runs and that is not an option
> right now. So the current solution is to just do it via init.d, but in
> the future we want udev.
What about the old hack that I had back in the old days that would let hcid
wait until D-Bus came up? ;-) One problem with init.d is that the daemon is
running, even if there is no device plugged in...
> The D-Bus service activation is nice, but makes
> problems when you wanna use the mouse and keyboard early.
Yes, I already noticed that :)
--
Stefan Seyfried
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
Hi Marcel,
> Another question, also related to packaging:
>
> How should the bluetoothd be started nowadays?
>
> dbus-activation with a service-file like this one?
> root@stoetzler:~# cat /usr/share/dbus-1/system-services/org.bluez.service
> [D-BUS Service]
> Name=org.bluez
> Exec=/etc/init.d/bluetooth start
> User=root
>
> But then, who will start it before XDM fires up? Has anybody already hacked up
> a nice way to just start it on adapter hotplug? Some HAL magic maybe?
>
> I had that old udev rule hack that would call the init script at adapter
> plugin, but that's ugly and racy (because it typically starts before DBus is
> started).
>
> Any innovative ideas?
we had the discussion for Fedora and we want to start it via udev,
however then we need D-Bus before udev runs and that is not an option
right now. So the current solution is to just do it via init.d, but in
the future we want udev. The D-Bus service activation is nice, but makes
problems when you wanna use the mouse and keyboard early.
Regards
Marcel
Hi Marcel,
Marcel Holtmann wrote:
>> So for now I'll go for the above list of packages, with libbluetooth3 instead
>> of bluez-libs.
>
> the Fedora packaging guidelines are kinda clear about how to name
> library packages. Same as for Debian. I don't know about SuSE.
The openSUSE packaging guidelines are what made me change the name to
libbluetooth3 ;)
> This is basically about the build dependencies and changing the devel
> package name means that you would need to adjust all sources relying on
> it.
Yes, understood and considered. However, the build gurus solved that with some
RPM specfile magic for me ;)
Another question, also related to packaging:
How should the bluetoothd be started nowadays?
dbus-activation with a service-file like this one?
root@stoetzler:~# cat /usr/share/dbus-1/system-services/org.bluez.service
[D-BUS Service]
Name=org.bluez
Exec=/etc/init.d/bluetooth start
User=root
But then, who will start it before XDM fires up? Has anybody already hacked up
a nice way to just start it on adapter hotplug? Some HAL magic maybe?
I had that old udev rule hack that would call the init script at adapter
plugin, but that's ugly and racy (because it typically starts before DBus is
started).
Any innovative ideas?
--
Stefan Seyfried
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
Hi Stefan,
> > Personally I like to see the bluez-utils package vanish and we are just
> > using bluez as main package name. Adding a virtual package bluetooth
> > that install all BlueZ packages would be nice to have, too.
> >
> > This would result in the following package names:
> >
> > bluez
> > bluez-libs
> > bluez-libs-devel
> > bluez-cups
> > bluez-alsa
> > bluez-gstreamer
>
> I like that too. I'd probably call it just "bluez-devel", since I won't have a
> bluez-libs (and libbluetooth3-devel is bad).
>
> What's important for me is that it is somehow consistent across distributions
> (which might also make it easier for you, in case the usual "cannot compile
> $foo" complaint is on the list, just tell them "install bluez-devel or
> bluez-libs-devel", no need to check which distribution the reporter is
> actually using).
>
> So for now I'll go for the above list of packages, with libbluetooth3 instead
> of bluez-libs.
the Fedora packaging guidelines are kinda clear about how to name
library packages. Same as for Debian. I don't know about SuSE.
This is basically about the build dependencies and changing the devel
package name means that you would need to adjust all sources relying on
it.
Regards
Marcel
Hi Marcel,
Marcel Holtmann wrote:
> Hi Stefan,
> it seems that everybody is keeping the package names as they are. So
> mainly you have bluez-utils and bluez-libs (libbluetooth in case of
> Debian).
That's fine with me. I will also have to change the name to libbluetooth3 too
because of package naming conventions (library packages need to be named after
the librarys SONAME), but that should be fine.
> The bluez-audio is the wrong approach and I commented on it already
> multiple times. Check the Fedora packages. So actual audio plugin should
> be part of bluez-utils since it has no dependencies whatsoever. And yes,
> it makes sense to have it without the ALSA and GStreamer plugins.
Ok.
> Check http://people.redhat.com/bnocera/bluez/bluez.spec for details.
Cool. I searched for some example bluez-4 spec file but did not find it ;-)
> Personally I like to see the bluez-utils package vanish and we are just
> using bluez as main package name. Adding a virtual package bluetooth
> that install all BlueZ packages would be nice to have, too.
>
> This would result in the following package names:
>
> bluez
> bluez-libs
> bluez-libs-devel
> bluez-cups
> bluez-alsa
> bluez-gstreamer
I like that too. I'd probably call it just "bluez-devel", since I won't have a
bluez-libs (and libbluetooth3-devel is bad).
What's important for me is that it is somehow consistent across distributions
(which might also make it easier for you, in case the usual "cannot compile
$foo" complaint is on the list, just tell them "install bluez-devel or
bluez-libs-devel", no need to check which distribution the reporter is
actually using).
So for now I'll go for the above list of packages, with libbluetooth3 instead
of bluez-libs.
Thanks,
Stefan
--
Stefan Seyfried
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
Hi Stefan,
> I'm packaging bluez-4.4 right now and just wanted to gather opinions about the
> package naming (it might be good if distributions could agree on consistent
> naming of packages).
>
> So how is everybody going to name the packages? The "old" ones for bluez-3.x
> were easy:
>
> - either bluez-libs or libbluetooth2 for the libs
> - bluez-utils for the hcid and hciconfig and related stuff
> - bluez-audio for the audio stuff (packaged separately because of
> the dependencies
> - bluez-cups for the cups backend
>
> From a first glance, I'd just keep the package-naming as is, but since it is a
> major version update anyway, if we want to change it, now might be a good time
> ;-)
>
> Opinions, anyone?
it seems that everybody is keeping the package names as they are. So
mainly you have bluez-utils and bluez-libs (libbluetooth in case of
Debian).
The bluez-audio is the wrong approach and I commented on it already
multiple times. Check the Fedora packages. So actual audio plugin should
be part of bluez-utils since it has no dependencies whatsoever. And yes,
it makes sense to have it without the ALSA and GStreamer plugins.
So Fedora has bluez-alsa (containing the libasound* bits) and
bluez-gstreamer (containing the libgst* bits).
Check http://people.redhat.com/bnocera/bluez/bluez.spec for details.
Personally I like to see the bluez-utils package vanish and we are just
using bluez as main package name. Adding a virtual package bluetooth
that install all BlueZ packages would be nice to have, too.
This would result in the following package names:
bluez
bluez-libs
bluez-libs-devel
bluez-cups
bluez-alsa
bluez-gstreamer
Regards
Marcel