John: In discussing further with the libcanberra maintainer, he had the following to say about canberra-gtk-play:
---- I meant that c-g-p may be used for similar purposes as zenity, not *by* zenity: it may be called from shell scripts and the like. For example, I am using a shell script that plays the "completion" sound via c-g-p after each "make" call. That way I get notified via sound when a long-running PA build finished compiling. If you guys ship zenity in /usr/bin, then you should ship c-g-p in /usr/bin too -- that's all I wanted to say. Think of jhbuild. We could extend it easily to call c-g-p for the completion sound after each build. However, for supporting Solaris we'd have to add some logic to check in which strange path you guys installed it in. I'd consider c-g-p as part of the API of libcanberra: not so much a C API, but an API for shell scripts, and that's why it should be present in $PATH. Or the other way round: following your logic that all binaries that aren't normally started directly by end users should be moved to libexec you should probably start moving the shell itself to libexec! And grep. And cc. And yacc. And so on. All those tools are only used by admins, hackers and shell scripts too! ---- Based on this, I think it is appropriate for it to be installed to bin, rather than libexec. Brian >> I am fine with all the answer except the one about canberra-gtk-play. >> Why should this program be in /usr/bin and not /usr/lib? It seems >> that it should be declared Project Private and contracts created >> for applications wanting to us it. Can you explain why that is >> not the case? > > I have discussed this on the libcanberra mailing list over the past few > days. Refer to the thread "Getting libcanberra working on Solaris": > > https://tango.0pointer.de/pipermail/libcanberra-discuss/2008-August/date.html > > > The maintainer suggests that this program is really only used by > various programs to play system sounds. Therefore, it sounds like > this belongs in libexec. However, the maintainer wants to keep it in > /usr/bin to make it easier to script from zenity and to make it easier > for developers to use it. > > I have highlighted that these are not really strong reasons for > putting this into /usr/bin. After all, developers should be smart > enough to run a program from libexec, and running it from a script > is not really an example of an "end user" needing to use it. > > The libcanberra maintainer seems resistant to moving the program, > and also seems resistant to making it possible to configure libcanberra > to install to a different location. He says we can obviously change > the way we package the module if we want, but it doesn't sound like > we will get any upstream support. > > Unless I can convince the maintainer otherwise, I think it might make > the most sense to ship this program in a consistent manner as upstream > in /usr/bin. If the committee feels strongly that we need to install > this to libexec, then we will need to maintain patches to do so. But > it is possible to move it to libexec if we want. > > Brian > > > >> Thanks, >> >> John >> >> On Thu, 2008-08-21 at 01:09, Brian Cameron wrote: >>> John: >>> >>> I would like this ARC case to also cover integrating of the >>> xdg-sound-theme module. I added the following text to the one-pager. >>> >>> Along with libcanberra, this case will also integrate the >>> xdg-sound-theme module. The xdg-sound-theme module only contains >>> audio media files which are installed to the >>> /usr/share/sounds/freedesktop directory. These are the default >>> sound >>> event sounds. >>> >>> As explained above, the xdg-sound-theme module only contains the actual >>> audio files for the default theme used by libcanberra. It doesn't >>> contain any code or anything particularly interesting. Releating to >>> this, I added the following two lines to the Exported Interface table >>> to cover these audio file theme installation interfaces. >>> >>> /usr/share/sounds Uncommitted XDG Sound >>> Theme >>> installation >>> directory. >>> /usr/share/sounds/freedesktop Volatile Default sound >>> theme. >>> >>>> Will the end user use canberra-gtk-play? Or is this >>>> only something that the library is intended to use? >>> The canberra-gtk-play program is intended to be used by programs >>> which want to play sound events. For example, the autostart desktop >>> file /usr/share/gnome/autostart/libcanberra-login-sound.desktop uses >>> canberra-gtk-play to play the login sound. >>> >>> I added the above paragraph to the one pager. >>> >>>> Are new applications expected to link to libraries >>>> within /usr/lib/libcanberra? If not then why isn't this directory >>>> and its contents Project Private? >>> No. These are plugins used by libcanberra itself. It isn't >>> private because an end user might want to write their own >>> plugin if they want libcanberra to support a different >>> audio output mechanism (such as ESD or something). The >>> intention is that end users can write their own plugins >>> as needed. >>> >>>> Why does it appear that the login and logout mechanisms >>>> are different from each other? The login is a desktop >>>> file and the logout is a shell script. Is this just a >>>> quarky Gnome thing? >>> These are the interfaces as defined by gnome-session. Refer >>> to the LSARC 2008/510 GNOME 2.24 ARC materials (the file >>> interface-table.txt) and you'll see that gnome-session installs a >>> "gnome-logout-sound.sh" file to the "shutdown" directory. >>> >>>> GTK+ is Uncommitted? I thought that it was Committed. >>>> In fact LSARC/2008/510 states that the GTK library is >>>> Committed. >>> Thanks for catching this. This is now updated in the case materials. >>> >>>> P.S. I have Cc-ed LSARC-ext instead of just LSARC >>>> as this case is open. >>> Thanks, >>> >>> Brian >> >
