[Question] Rename bluealsa and bluealsa-cli execs

[arkq]

It seems that in the Linux world it is very natural to name applications which "control" things as CTLs, e.g. bluetoothctl, systemctl. In the original PR for "bluealsa-client" #413, there was some discussion how to name this tool and I opted for bluealsa-cli. Right now I can see that maybe that was a bad idea. So, I'm wondering how good/bad for community would be to change exec names....

I'm thinking about changing names for bluealsa service and bluealsa-cli (which right now seems more like "control" than "client"):

• bluealsa -> bluealsad (this will alight with bluetoothd, ofonod, and other system daemons)
• bluealsa-cli -> bluealsactl (this might be more nature for people who are familiar with systemctl and other CTLs)

I'd like to hear some opinion from anyone who uses this project in some way and from package maintainers (maybe there were some rename cases like that in other projects and what were the outcomes of such decisions).

[paul-1]

I would agree with your proposed naming convention. It make sense in corrdination with other bluez based apps and daemons. I think the only apps using the -cli naming, is wpa-supplicant and hostapd.

Early on with bluealsa, I developed everything using dbus directly (combination of gdbus for command-line interaction with my web interface, or dbus-python in my connection handling app. At the end of the day, I do deploy these apps for users to do troubleshooting if needed and similar naming might help.

[lightdot]

This change makes perfect sense. It's not strictly necessary, but it would offer a cleaner UI to those that are familiar with the other software packages.

[borine]

This issue has been idle for a very long time now. It's a shame that it does not seem to have caught the attention of maintainers of distributions that use BlueALSA as a core component (e.g. osmc, moode audio and many others). So, given that after more than 18 months there have been no objections, perhaps now is the time to prepare for this change in the master branch. I think the choice is either to push out a new release first so that the current updates are tagged before the name changes; or else to make the name changes ASAP then delay the next release until downstream projects have had time to assess their own packaging and documentation impact of the change.

[arkq]

I think the choice is [...] to push out a new release first so that the current updates are tagged before the name changes

I would go with such approach.

I think that the new release is just behind the corner. Two most important changes from my point of view are already there: BLE-MIDI and LC3-SWB. I've been thinking about adding support for LHDC before tagging new release, but I will not merge that PR before the library is publicly available (without that it's not possible for me to maintain that feature). Also, I've been thinking about dropping GPL readline dependency in favor of BSD-licensed libedit (in 2019 the support for event loop based processing has been added). But maybe such change should also be done after current release because it's not a straightforward library replace (something is not working right with libedit, so changes in the bluealsa-rfcomm are required).