[pulseaudio-discuss] PulseAudio support on Solaris
Lennart Poettering
lennart at poettering.net
Mon Oct 17 04:30:07 PDT 2011
On Mon, 17.10.11 10:33, Colin Guthrie (gmane at colin.guthr.ie) wrote:
>
> 'Twas brillig, and Lennart Poettering at 17/10/11 02:48 did gyre and gimble:
> >> 3) On Solaris, the PulseAudio GConf module does not compile since the
> >> "module_info" structure defined in the PulseAudio code conflicts
> >> with a structure with the same name in /usr/include/sys/stream.h.
> >> Could the PulseAudio code be updated to use a more unique PulseAudio
> >> specific name as suggested in the patch in this bug:
> >>
> >> https://bugs.freedesktop.org/show_bug.cgi?id=41823
> >>
> >> Note that sys/stream.h is included by sys/types.h on Solaris, and
> >> sys/types.h is included in the src/modules/gconf/modules-gconf.c
> >> PulseAudio file.
> >
> > The GConf code probably should go away anyway, and be replaced by dconf/gsettings.
>
> While dconf/gsettings is an option, I'd be more in favour personally of
> using whatever pa_database* stuff we use (this was my intension in this
> area with module-loader).
Well, private database do not have change notificiation, which makes
them a pretty useless replacement.
> I'm certainly not against dconf or whatever, but if we do migrate
> module-gocnf to it, then I'd prefer to see dconf as a universal database
> provider in PA like gdb, tdb, plaintext etc. Having two different
> mechanisms of writing data to disk doesn't seem like the wises plan overall.
Nah, I don't really agree. Configuration is configuration. Remembering
state or learned rules is remembering state or learned rules. The former
is something you might want to share with other apps, the latter
something that is private to you. The former is something you need to
have a clear schema for, so that external code can interfere with it,
but this isn't needed that much for the latter.
Lennart
--
Lennart Poettering - Red Hat, Inc.
More information about the pulseaudio-discuss
mailing list