[Pkg-bluetooth-maintainers] bluez-utils_3.5-1 package

[Filippo Giunchedi]

Dear Marcel,

On Sat, Sep 23, 2006 at 11:22:14AM +0200, Marcel Holtmann wrote:
> Hi,
> 
> I looked at the bluez-utils_3.5-1 package and found some weird things
> that needs to be fixed. Running diffstat on bluez-utils_3.5-1.diff.gz
> showed me this:
> 
>  ...
>  debian/patches/002_hcid_conf_defaults.patch |   20 
>  debian/patches/005_l2ping_section.patch     |    8 
>  debian/patches/008_pand_man.patch           |    9 
>  debian/patches/009_rfcomm_anycommand.patch  |   18 
>  debian/register-passkeys                    |   19 
>  debian/rules                                |   59 ++
>  debian/rules                                |   59 ++
>  pand/pand.1                                 |    3 
>  rfcomm/main.c                               |    9 
>  40 files changed, 2654 insertions(+), 10 deletions(-)
> 
> Please don't patch upstream source and revert changes to make your
> patches apply later on. Remove the patches that are merged upstream
> and/or update them to keep the package clean. Directly patching the
> upstream source if always the wrong approach.

I must have overlooked this, I agree that patches to upstream must be kept
separate.

> 
> The suggestion of any Python interpreter is also an obsolete relict from
> some ancient times:
> 
> Suggests: python-gtk2, python (>= 1.5)
> 
> We included a PIN helper script written in Python. The PIN helper
> concept is dead and the Python script has been removed for quite some
> time now. Time to get rid of it.

ack on this.

> 
> I would purpose to suggest the bluez-firmware and bluez-gnome package
> instead.

ack.

> 
> The udev scripts are now included in the upstream package and I suggest
> that you simple use these instead of carrying around your own stuff.
> Enable them and then make sure they install into the right directory.
> The upstream README contains information on how to call configure
> correctly to get them installed in the correct location.

they are in fact almost the same file, I'll fix this.

> 
> If you need changes to these scripts, then include a patch that does it
> instead of carrying a copy around.
> 
> The package also has a lot of manual pages in it that are already merged
> upstream. Please remove them.

ack.

> 
> Starting to enable stuff like --enable-obex makes no sense at the
> moment, because these things are all in development and they will not be
> installed by default.

so it makes no damage either :) 

> 
> And last, but not least, the Debian specific passkey thing must go away.
> This is a Debian specific way and no other distribution is doing
> something like this. It is total crap and will make the correct use of
> the passkey agent interface from other applications impossible. You must
> trust me here. You lack the understanding on how this is meant to work
> and you are abusing it with the number of processes that you start and
> it is not even gonna work as you think. The device specific agents will
> timeout or get removed after its first use and the default passkey agent
> will block applications like bt-applet. A passkey is meant to be started
> by a user session and not system wide from an init script.

What to do if Xwindow is not available?
Suppose you are in console and do an outgoing connection or pairing, what the
passkey agent is supposed to do?

So let's see I if got it:
- document somewhere that the user should start the (commandline, in this case) agent
- the (commandline) agent will read passkeys from the user's $HOME
can this be a viable solution for you?

filippo