John: > 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 >
