Packaging question
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
Quoted 1 line
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?
Signature · 6 lines
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)
Marcel Holtmann
maintainerHi Stefan,
Quoted 13 lines
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
Quoted 5 lines
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
Hi Marcel,
Quoted 5 lines · Marcel Holtmann
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.
Quoted 4 lines
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.
Quoted 1 line
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 ;-)
Quoted 4 lines
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.
Quoted 8 lines
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
Signature · 6 lines
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)
Marcel Holtmann
maintainerHi Stefan,
Quoted 16 lines
Quoted 4 lines
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.
Quoted 8 lines
This would result in the following package names:
bluez
bluez-libs
bluez-libs-devel
bluez-cups
bluez-alsa
bluez-gstreamerI like that too. I'd probably call it just "bluez-devel", since I won't have a bluez-libs (and libbluetooth3-devel is bad).
Quoted 8 lines
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,
Quoted 5 lines · Marcel Holtmann
Quoted 2 lines
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 ;)
Quoted 3 lines
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?
Signature · 6 lines
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)
Marcel Holtmann
maintainerHi Marcel,
Quoted 11 lines
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
Quoted 8 lines
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
Quoted 10 lines · Marcel Holtmann
Quoted 5 lines
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...
Quoted 2 lines
The D-Bus service activation is nice, but makes problems when you wanna use the mouse and keyboard early.
Yes, I already noticed that :)
Signature · 6 lines
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)
Marcel Holtmann
maintainerHi Stefan,
Quoted 8 lines
Quoted 4 lines
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
Hi Marcel (and everybody else still listening),
Quoted 3 lines · Marcel Holtmann
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
Signature · 6 lines
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)