All, I am fine with this. Since there are no other issues I am closing this case as approved.
Thanks, John Brian Cameron wrote: > > 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 >>> >> >
