packaging question

packaging question

[Dmitry Baryshkov]

Hi,

To make suspend work on tosa w/o problems, I have to put several files into
apm hooks directories. The question is: into which OE package should I put them?

-- 
With best wishes
Dmitry

Re: packaging question

[Paul Sokolovsky]

Hello,

On Sat, 29 Nov 2008 00:17:37 +0000 (UTC)
Dmitry Baryshkov <dbaryshkov@gmail.com> wrote:

> Hi,
> 
> To make suspend work on tosa w/o problems, I have to put several
> files into apm hooks directories. The question is: into which OE
> package should I put them?

This was discussed well once - please put all machine- and device-
specific hacks and workarounds into separate package(s), to not
contaminate the main device-independent package with them, which would
either cast the main package machine-specific (QA nightmare), or affect
other devices unexpectedly (even bigger QA nightmare). There're few
examples of this idea already, see apm-wifi-suspendfix,
bluez-dtl1-workaround packages.

If such a package is machine specific, it's obvious where it should go
- into MACHINE_EXTRA_RDEPENDS. If it's however a workaround for
a particular device, especially pluggable, it makes sense to make it
more flexible and automagical and associate with the corresponding
kernel driver. See kernel.bbclass for how the packages above are
handled.

> 
> -- 
> With best wishes
> Dmitry

[]

-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: packaging question

[Dmitry]

2008/11/29 Paul Sokolovsky <pmiscml@gmail.com>:
> Hello,
>
> On Sat, 29 Nov 2008 00:17:37 +0000 (UTC)
> Dmitry Baryshkov <dbaryshkov@gmail.com> wrote:
>
>> Hi,
>>
>> To make suspend work on tosa w/o problems, I have to put several
>> files into apm hooks directories. The question is: into which OE
>> package should I put them?
>
> This was discussed well once - please put all machine- and device-
> specific hacks and workarounds into separate package(s), to not
> contaminate the main device-independent package with them, which would
> either cast the main package machine-specific (QA nightmare), or affect
> other devices unexpectedly (even bigger QA nightmare). There're few
> examples of this idea already, see apm-wifi-suspendfix,
> bluez-dtl1-workaround packages.
>
> If such a package is machine specific, it's obvious where it should go
> - into MACHINE_EXTRA_RDEPENDS. If it's however a workaround for
> a particular device, especially pluggable, it makes sense to make it
> more flexible and automagical and associate with the corresponding
> kernel driver. See kernel.bbclass for how the packages above are
> handled.

Should I also bump PR of task-base after changing MACHINE_EXTRA_RRECOMMENDS?

>
>>
>> --
>> With best wishes
>> Dmitry
>
> []
>
> --
> Best regards,
>  Paul                          mailto:pmiscml@gmail.com
>



-- 
With best wishes
Dmitry

Re: packaging question

[Koen Kooi]

On 03-12-08 01:11, Dmitry wrote:
> 2008/11/29 Paul Sokolovsky<pmiscml@gmail.com>:
>> Hello,
>>
>> On Sat, 29 Nov 2008 00:17:37 +0000 (UTC)
>> Dmitry Baryshkov<dbaryshkov@gmail.com>  wrote:
>>
>>> Hi,
>>>
>>> To make suspend work on tosa w/o problems, I have to put several
>>> files into apm hooks directories. The question is: into which OE
>>> package should I put them?
>> This was discussed well once - please put all machine- and device-
>> specific hacks and workarounds into separate package(s), to not
>> contaminate the main device-independent package with them, which would
>> either cast the main package machine-specific (QA nightmare), or affect
>> other devices unexpectedly (even bigger QA nightmare). There're few
>> examples of this idea already, see apm-wifi-suspendfix,
>> bluez-dtl1-workaround packages.
>>
>> If such a package is machine specific, it's obvious where it should go
>> - into MACHINE_EXTRA_RDEPENDS. If it's however a workaround for
>> a particular device, especially pluggable, it makes sense to make it
>> more flexible and automagical and associate with the corresponding
>> kernel driver. See kernel.bbclass for how the packages above are
>> handled.
>
> Should I also bump PR of task-base after changing MACHINE_EXTRA_RRECOMMENDS?

and task-boot where appropriate.

regards,

Koen


>
>>> --
>>> With best wishes
>>> Dmitry
>> []
>>
>> --
>> Best regards,
>>   Paul                          mailto:pmiscml@gmail.com
>>
>
>
>

Packaging question

[Stefan Seyfried]

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)

Re: Packaging question

[Marcel Holtmann]

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

Re: Packaging question

[Stefan Seyfried]

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)

Re: Packaging question

[Marcel Holtmann]

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

Re: Packaging question

[Stefan Seyfried]

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)

Re: Packaging question

[Marcel Holtmann]

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

Re: Packaging question

[Stefan Seyfried]

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)

Re: Packaging question

[Marcel Holtmann]

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

Re: Packaging question

[Stefan Seyfried]

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)