On Sun, 24.08.08 13:12, Brian Cameron ([EMAIL PROTECTED]) wrote: >> The tool might be useful for similar purposes as "zenity": for >> scripting purposes. > > When run from zenity, it is being run from a program rather than a > user. Normally libexec is used for things that are typically run from > programs.
As already pointed out by Colin 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 thelike. 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! I mean, you Sun guys claim that API stability and standardization is oh so important to you, at least that was the reason you gave when you violated my lovely Avahi the way you did when you adopted it for Solaris. Is it so difficult to understand that I consider having c-g-p in $PATH to be somewhat part of libcanberra's API? You are welcome to deviate from that, it's Free Software after all, but please, don't ask me to do this for you upstream. Also note that there isn't a single C line I was aware of that has a hardcoded c-g-p invocation via system() or exec(). >> I'd prefer if people could rely on the existance of this tool in a >> certain path. > > If someone could give a reasonable argument why it belongs in /usr/bin > rather than /usr/libexec, then I am sure Sun's Architecture Review > Committee would not have a problem with it in /usr/bin. Providing > it for developer purposes, or for making it available for scripting > are not strong examples, though. Dude, I don't really care where some random committee likes put things. What I do care is that my upstream packages are somewhat clean and stable in the API, and that if the tarball is built you get something that works for most people and isn't totally different for each and everyone. >> Of course I can't tell you guys how to package this, but >> please, if you move this, then do it by a Solaris-specific patch on >> top of upstream libcanberra. > > If someone provides a working patch to specify where it is installed, > why wouldn't it make sense to just accept it upstream? It seems > sensible to allow people to configure the module as they want, rather > than making people configure it when packaging. For the same reason that I wouldn't take a patch that, let's say, extended libcanberra's API to support playing Jingle Bells on your USB marimba for each event sound. I wouldn't want to see this exposed in the API, because I don't want to support this in the API. >> Somehow I managed to ignore that second iteration of the patches and >> didn't review them when Marc-Andre posted them. However, a few minutes >> ago I finally reviewed them with Marc-Andre on IRC. He plans to rebase >> them on current libcanberra. > > Great, does this mean that GStreamer will just be supported > out-of-the-box with the next libcanberra release? That's great. Or > do you need further help to make the code ready? Note sure about the *next* libcanberra release. That depends entirely on whether I get a good, mergable patch by then. Consider working with Marc-Andre to get it ready quickly. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ libcanberra-discuss mailing list [email protected] https://tango.0pointer.de/mailman/listinfo/libcanberra-discuss
